blast-hardcheese on core-v0.75.2
blast-hardcheese on master
Update akka-http, akka-http-tes… Merge pull request #1576 from s… (compare)
blast-hardcheese on master
Update scala-library, scala-ref… Update wartremover.sbt Update scoverage.sbt and 2 more (compare)
blast-hardcheese on master
Trying to work around codecov b… (compare)
required=true,nullable=falsecase, that the server should accept a request where the field is missing (or maybe eve null), but substitute the default when calling the handler? that seems a little weird to me, because to me the required/nullable knobs to me talk about the wire format, and
required=true,nullable=falsemeans that a request where that field is missing or null is an invalid request
"whatever": nullexample wherein you say "substitute the default if you see null"
Presenceclass to say
required: trueor something
"whatever": nullon the server when
required=falseto end up giving them the default value in the handler.
i think the thing i'm struggling with is if we should be interpreting the required, nullable, and default as instructions about the wire format, or about the UX of the server or client, or in some cases both. i think it's pretty safe to assume that required and nullable are first and foremost about the wire format, though they can affect the UX of the client and server. whereas default might be entirely about the UX of the client and server.... but we still have to make those UX decisions in the context of the wire format.
like if someone says
required=false,nullable=true,default=foobar, are they saying "i just want to have a really permissible wire format, where you can leave the field out or set it to null, and no one cares, but the UX should never see a null/absent and should always have
foobar substituted when there's no value or no field"?
or are they saying "absent field means they don't care and we should substitute the default, and
null means they specifically want no value and we should pass that through"?
but then i try to think about the actual use cases. since CRUD is a big use case, i think... ok, on
create, you probably mean the first thing. i can't think of a non-bonkers API where creating a resource has a field where you can either ask for the default, ask for null, or set a value. that just seems weird to me. but maybe someone wants to do that? then i think about
update, and my feeling there is that a default doesn't ever really make sense. in that case absent has to mean "don't modify this field", null has to mean "set this field to null", and a value has to mean "set this value". and if someone does set a default value for a field in an
update, i would say they are doing it wrong, because that doesn't make sense.
so maybe we can just say... ok, if you provide a default, we'll of course obey required/nullable when it comes to the wire format, but from the perspective of the server (when handling a request) or client (when inspecting a response), there is no such thing as absent or null. that property always has a value, and if we don't see one on the wire, that value is the default value. and yes, that means that if someone puts a default on their
update operation, things might be broken, but that's kinda on them for doing something logically nonsensical.
outside of CRUD, are there places where someone might want that "absent=default, null=null, value=value" interpretation of what comes over the wire? maybe? can we come up with something concrete, or is this just navel-gazing? the problem is that if we decide that there's nothing concrete here, and don't allow that interpretation, and then someone comes along and says they need it, we can't support it without either breaking existing behavior (nope) or adding another command-line switch to enable it. but on the flip side, if we do add support for this case from the start, at least people who don't care about this distinction (and just want "absent=default, null=default, value=value") can still implement that in their services without too much trouble (but yes, to be fair, the UX there ends up being slightly sub-optimal).
to make sure we're talking about the same possibilities, we've got...
Is that correct?
TraceBuilderis really a relic, considering the new request/response transformers. I was initially against having those, as they permit complete violation of the spec or schema, but after wrestling with TraceBuilder for so long, I was really brought around to the more pragmatic, general solution.
guardrail-contriblibrary dependency that fits that function signature to add a bit more structure, in a modular way
TraceBuilderstuff was modeled around some abstractions we had in Twilio for integrating with Lightstep, datadog APM wasn't available to use at that time
The migration has already been merged, (0.64.4 was actually already accidentally released under dev.guardrail with the package changes), the only follow-up changes are to sbt-guardrail, guardrail-maven-plugin, and guardrail-gradle-plugin. If any of those strike your fancy, that would be tremendously helpful.
Once the new plugins under the new org are available, my plan is to cut a hotfix on the 0.64.x branch in the old org that includes a log line to advise consumers to switch over to the new org in order to continue getting updates via scala-steward or dependabot
target/, without any sort of eviction if you fix the problem.
com.twilioand publish the same version to both, to give an opportunity for scala-steward to prompt for upgrades to a version that also prints a warning about the organization change
guardrail-dropwizard, or otherwise? A problem I'm trying to solve is to stop the seeming runaway train that is attempted semver split across so many subprojects