Skip to content

Fallback to standard string handling for unknown "format" values #64

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

Closed
acgray opened this issue Jun 8, 2020 · 1 comment
Closed

Fallback to standard string handling for unknown "format" values #64

acgray opened this issue Jun 8, 2020 · 1 comment
Labels
✨ enhancement New feature or improvement
Milestone

Comments

@acgray
Copy link

acgray commented Jun 8, 2020

Is your feature request related to a problem? Please describe.
If a string field uses an arbirtrary custom "format" value, as allowed by the OpenAPI spec, it is rejected by the parser.

Describe the solution you'd like
As it is guaranteed to be a string, even if the exact format is unknown, I suggest that the parser should follow the recommended behaviour in the spec and fall back to handling the field as a plain string. This is the behaviour recommended by the specification:

Tools that do not support a specific format may default back to the type alone, as if the format is not specified.

@acgray acgray added the ✨ enhancement New feature or improvement label Jun 8, 2020
acgray pushed a commit to acgray/openapi-python-client that referenced this issue Jun 8, 2020
@dbanty dbanty added this to the 0.4.2 milestone Jun 8, 2020
@dbanty
Copy link
Collaborator

dbanty commented Jun 13, 2020

Changes are merged in and will be available in 0.4.2.

@dbanty dbanty closed this as completed Jun 13, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
✨ enhancement New feature or improvement
Projects
None yet
Development

No branches or pull requests

2 participants