feat: Reference schema support (#800)#1307
Merged
dbanty merged 4 commits intoopenapi-generators:mainfrom Sep 13, 2025
Merged
Conversation
dbanty
approved these changes
Sep 13, 2025
Collaborator
dbanty
left a comment
There was a problem hiding this comment.
Looks great to me, thanks!
Merged
github-merge-queue bot
pushed a commit
that referenced
this pull request
Sep 13, 2025
> [!IMPORTANT] > Merging this pull request will create this release ## Features - Reference schema support (#800) (#1307) - Support Ruff 0.13 Co-authored-by: knope-bot[bot] <152252888+knope-bot[bot]@users.noreply.github.com>
This file contains hidden or 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
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 PR adds support for reference schemas (#800).
The idea with this change is that during parsing of the schemas, when the parser encounters a
Referenceschema, rather than aborting it will attempt to fully resolve that reference by following the chain of references until it encounters aSchema. When it does, it will attempt to fetch that parsedSchemafrom the dictionary of available components, which should include all possible referent schemas. If it exists, it will parse the current/original reference Schema as if it was its ultimate referent. If it reaches a reference that does not exist, it logs an error and moves on: it won't be able to parse thisReference.The result of this is that every reference schema in the API doc will result in a separate-but-identical class, aside from the class name. This feels like a safe, basic way to handle the situation, since collapsing identical classes might break compatibility between the API and the codegen at some point. I suppose we could instead have references be subclasses or some trick like that to cut down on code duplication and let identical API objects be equivalent? If that would be preferable it is probably doable downstream of this change, since with this parsing the
Schemaobjects added as references in theSchemasclass should be identical objects which could be identified and collapsed in some fashion during code templating. Perhaps it would be useful to record the direction of references during parsing to better choose what a base class would be... That would require some more thought.In any case, this works both for single references as well as arbitrarily deep nested references, something useful for the API I'm developing for.
Also includes some functional tests which include both a valid and invalid (circular reference) case for reference schemas and adjusts an existing unit test which assumed that the reference schema would be skipped to one that tests whether it has been parsed.