Schema overhaul #140
Merged
Schema overhaul #140
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Baccata
force-pushed
the
schema-overhaul
branch
from
fc756df to
022adec
Compare
|
random notes found while playing with this:
|
* Adds `checked` methods on Schema and Field * Adds some black-magic to shoe-horn refinements into fields * Fix some tests in the json module
Best effort parsing happens if: * no errorTypeHeader is found to discriminate * status code matches multiple error type or no error type In this case, the following logic happens: * we try to decode for every union alternative * first success wins * order is "smart" (see below) Ordering of the alternatives depends on the status code. If status is in the 4xx, then generic client error are placed first, otherwise it's server ++ client ++ the rest. See https://awslabs.github.io/smithy/1.0/spec/core/http-traits.html#httperror-trait Note: if one of the alternative has only optional event, chances are that parsing will be successful
Schema overhaul
Better error handling on the client
Schema overhaul surjection
Baccata
added a commit
that referenced
this pull request
May 10, 2022
This is an overhaul of the "schema/schematic" abstraction to make use of a GADT. We're trading off extensibility for ease of implementation for interpreters. In particular, having a GADT at hand allows us to peek into the structure of a schema (and the hints carried at each layer), several layers down, without a need for ad-hoc constructs such as `Hinted` and such. It also allows interpreters to delegate to other interpreters when convenient. It also adds the notion of `surjection` in the schema, which allow to capture transformations that work only on a subset of the type of the schema. The usefulness of it has to do with making it easier for downstream implementors to incorporate validation concerns within the decoders. Additionally, traits that imply validation of the incoming data (range/length/pattern) are now receiving specific treatment during codegen in order for the schemas containing them to leverage the surjection. Co-authored-by: Jakub Kozłowski <kubukoz@gmail.com> Co-authored-by: David Francoeur <dfrancoeur04@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is an overhaul of the "schema/schematic" abstraction to make use of a GADT. We're trading off extensibility for ease of implementation for interpreters. In particular, having a GADT at hand allows us to peek into the structure of a schema (and the hints carried at each layer), several layers down, without a need for ad-hoc constructs such as
Hintedand such.It also allows interpreters to delegate to other interpreters when convenient.