Skip to content

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

Merged
merged 5 commits into from
Apr 19, 2024

Conversation

peter-greenatlas
Copy link
Contributor

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 a Literal 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 a oneOf 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 the const 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:

In OAS 3.0, a response payload MAY be described to be exactly one of any number of types:
[...]
which means the payload MUST, by validation, match exactly one of the schemas described by Cat, Dog, or Lizard.

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.

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.
@dbanty
Copy link
Collaborator

dbanty commented Apr 19, 2024

I think this aligns with the rest of the project. For example, if a string that's supposed to be of format date-time cannot be parsed, a ValueError is also thrown (from dateutil). We will mark this as a breaking change so folks are aware but I don't think it strays from existing practice.

@dbanty dbanty added the 🥚breaking This change breaks compatibility label Apr 19, 2024
Copy link
Collaborator

@dbanty dbanty left a 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!

@dbanty dbanty enabled auto-merge April 19, 2024 22:31
@dbanty dbanty added this pull request to the merge queue Apr 19, 2024
Merged via the queue into openapi-generators:main with commit ee052fd Apr 19, 2024
20 checks passed
dbanty added a commit that referenced this pull request May 18, 2024
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]>
micha91 pushed a commit to micha91/openapi-python-client that referenced this pull request May 13, 2025
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]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🥚breaking This change breaks compatibility
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants