-
-
Notifications
You must be signed in to change notification settings - Fork 229
validate value of 'const' properties (helps with discriminated unions) #1024
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
validate value of 'const' properties (helps with discriminated unions) #1024
Conversation
For 'const' properties, the parsed value will now be checked against the value in the schema at runtime and a ValueError will be raised if they do not match. This helps with parsing `oneOf` when matching a const property is the only way to resolve which of the types should be returned.
I think this aligns with the rest of the project. For example, if a string that's supposed to be of format |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the improvement!
This PR was created by Knope. Merging it will create a new release ### Breaking Changes #### `const` values in responses are now validated at runtime Prior to this version, `const` values returned from servers were assumed to always be correct. Now, if a server returns an unexpected value, the client will raise a `ValueError`. This should enable better usage with `oneOf`. PR #1024. Thanks @peter-greenatlas! #### Switch YAML parsing to 1.2 This change switches the YAML parsing library to `ruamel.yaml` which follows the YAML 1.2 specification. [There are breaking changes](https://yaml.readthedocs.io/en/latest/pyyaml/#defaulting-to-yaml-12-support) from YAML 1.1 to 1.2, though they will not affect most use cases. PR #1042 fixes #1041. Thanks @rtaycher! ### Features - allow Ruff 0.4 (#1031) ### Fixes #### Fix nullable and required properties in multipart bodies Fixes #926. > [!WARNING] > This change is likely to break custom templates. Multipart body handling has been completely split from JSON bodies. Co-authored-by: GitHub <[email protected]>
This PR was created by Knope. Merging it will create a new release ### Breaking Changes #### `const` values in responses are now validated at runtime Prior to this version, `const` values returned from servers were assumed to always be correct. Now, if a server returns an unexpected value, the client will raise a `ValueError`. This should enable better usage with `oneOf`. PR openapi-generators#1024. Thanks @peter-greenatlas! #### Switch YAML parsing to 1.2 This change switches the YAML parsing library to `ruamel.yaml` which follows the YAML 1.2 specification. [There are breaking changes](https://yaml.readthedocs.io/en/latest/pyyaml/#defaulting-to-yaml-12-support) from YAML 1.1 to 1.2, though they will not affect most use cases. PR openapi-generators#1042 fixes openapi-generators#1041. Thanks @rtaycher! ### Features - allow Ruff 0.4 (openapi-generators#1031) ### Fixes #### Fix nullable and required properties in multipart bodies Fixes openapi-generators#926. > [!WARNING] > This change is likely to break custom templates. Multipart body handling has been completely split from JSON bodies. Co-authored-by: GitHub <[email protected]>
For 'const' properties, the parsed value will now be checked against the value in the schema at runtime and a ValueError will be raised if they do not match. Until now, the values would just be
cast
to aLiteral
without checking.This helps with with parsing
oneOf
when matching a const property is the only way to resolve which of the types should be returned. i.e. if aoneOf
contains two schemas, but the properties in one are a subset of the other, then the only way to know which one to return is to validate theconst
value.I know that for the most part this library parses but doesn't validate, but I don't see a way around it in this case. The spec itself mentions validation when talking about
oneOf
:Note that this also addresses some of the use cases for discriminated unions. Per the spec, the
a discriminator MAY act as a "hint" to shortcut validation and selection of the matching schema which may be a costly operation, depending on the complexity of the schema.
so implementing discriminators would be a speedup but with this change we'll at least construct the correct type.I'm happy to take any feedback, or abandon this if you don't like fact that it is validation. I originally went to try to implement discriminated unions fully, but this seemed like a much easier step towards that that gets the same result.