feat: Reference schema support (#800) #1307
Merged
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
Reference
schema, 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 parsedSchema
from 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
Schema
objects added as references in theSchemas
class 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.