OpenApi 3.1.0 #58
Draft
OpenApi 3.1.0 #58
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
Co-authored-by: James Hinshelwood <[email protected]>
Co-authored-by: James Hinshelwood <[email protected]>
Co-authored-by: James Hinshelwood <[email protected]>
Co-authored-by: James Hinshelwood <[email protected]>
Co-authored-by: James Hinshelwood <[email protected]>
Co-authored-by: James Hinshelwood <[email protected]>
…vel version switch under a module
…vel version switch under a module
Closed
|
Is there ETA on this, what can I do to help driving it forward? I have a tool that uses schemars for schema generation but with own type definitions. It would be great to transition to this instead. |
|
@tamasfe I'm increasingly of the opinion that using |
|
I see, thanks. That's unfortunate, it's currently the best schema generator library and having its schema types among the openapi types has been very convenient for me. |
|
Totally! It would be great if it were being diligently maintained. |
yoav-lavi
pushed a commit
to grafbase/grafbase
that referenced
this pull request
Sep 5, 2023
This PR adds support for OpenAPI 3.1 to the OpenAPI connector. Despite the name, 3.1 is a breaking change from 3.0. The primary change is that schemas are now JSON schema, rather than some bizarre "subset superset" . There's no currently released crate that has support for OpenAPI 3.1, but there is a fork of our existing openapiv3 library that adds support. I've forked that fork into the `grafbase` org for now - it was behind on a couple of patches so I've merged those in. There is [a PR to merge this back into the actual crate](glademiller/openapiv3#58) but it looks kind of like that'll never be merged. Guess we might want to revisit when/if there's an actual release with support. Anyway, unfortunately this version of the crate has made some choices around how to structure schemas that are _completely_ different from the v3 approach (a common OpenAPI problem - if there is a different way to do things you can guarantee someone has). So this required a fair bit of new code - similar to adding v2 I've just added another folder in `parsing` that takes v3.1 and puts it onto the same intermediate graph as the other versions use. Then the rest of the code can be shared. ### Testing - Orb spec seems to work, there's a test in this PR. - The Mongo Atlas API is also 3.1, but it doesn't work yet - it's doing some things that break some of my assumptions, so will need to do a follow up PR to fix that. - If anyone knows of other 3.1 specs I could test with please shout
|
@ahl do you still hold that opinion with current maintenance levels? A quick glance shows rather frequent commits and going towards a 1.0.0 release? |
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 continues the work from #55
There are some additional changes:
From<v3_0> for v3_1versioned(need a better name)large_enum_variantallowances)