Fix an issue where JSON schema member names collided #200
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
TODO: break this API to make this work more reliably. This is addressed by temporarily setting a de-conflicting ref strategy. This is the minimal change needed to fix a reported bug, but it is a hack and we should break this API before GA. We want to do the right thing by default. However, the default that was previously chosen didn't account for the possibility of shape name conflicts when converting members to JSON schema pointers. For example, consider the following shapes: - A member of a list, foo.baz#PageScripts$member - A member of a structure, foo.baz#Page$scripts If we only rely on the RefStrategy#createDefaultStrategy, then we would actually generate the same JSON schema shape name for both of the above member shapes: FooBazPageScriptsMember. To avoid this, we need to know the shape index being converted and automatically handle conflicts. However, because this class is mutable, we have to do some funky stuff with state to "do the right thing" by lazily creating a RefStrategy#createDefaultDeconflictingStrategy in this method once a ShapeIndex is available (given as an argument). A better API would use a builder that builds a JsonSchemaConverter that has a fixed shape index, ref strategy, etc. This would allow ref strategies to do more up-front computations, and allow them to even become implementation details of JsonSchemaConverter by exposing a similar API that delegates from a converter into the strategy. There's also quite a bit of awkward code in the OpenAPI conversion code base that tries to deal with merging configuration values and deriving a default JsonSchemaConverter if one isn't set. A better API there would be to not even allow the injection of a custom JsonSchemaConverter at all.
kstich
approved these changes
Nov 5, 2019
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.
TODO: break this API to make this work more reliably.
This is addressed by temporarily setting a de-conflicting ref
strategy. This is the minimal change needed to fix a reported
bug, but it is a hack and we should break this API before GA.
We want to do the right thing by default. However, the default
that was previously chosen didn't account for the possibility
of shape name conflicts when converting members to JSON schema
pointers. For example, consider the following shapes:
If we only rely on the RefStrategy#createDefaultStrategy, then
we would actually generate the same JSON schema shape name for
both of the above member shapes: FooBazPageScriptsMember. To
avoid this, we need to know the shape index being converted and
automatically handle conflicts. However, because this class is
mutable, we have to do some funky stuff with state to "do the
right thing" by lazily creating a
RefStrategy#createDefaultDeconflictingStrategy in this method
once a ShapeIndex is available (given as an argument).
A better API would use a builder that builds a JsonSchemaConverter
that has a fixed shape index, ref strategy, etc. This would allow
ref strategies to do more up-front computations, and allow them to
even become implementation details of JsonSchemaConverter by exposing
a similar API that delegates from a converter into the strategy.
There's also quite a bit of awkward code in the OpenAPI conversion code
base that tries to deal with merging configuration values and deriving
a default JsonSchemaConverter if one isn't set. A better API there would
be to not even allow the injection of a custom JsonSchemaConverter at all.
Issue #, if available:
Description of changes:
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.