codegen: permit parent properties in one of children #3958
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.
It turns out that children of oneOf declarations with a discriminator should have the discriminator declared as a property (cf https://swagger.io/docs/specification/data-models/inheritance-and-polymorphism/), and some other openapi tooling gets broken if the children do not have that property declaration. We cannot simply declare the discriminator property on a child to be a standard field since that breaks jsoniter adt codecs (for jsoniter, the discriminator must not be a field on the child class). I also didn't like the idea of dropping the property entirely from the child if it's declared in the openapi yaml, since that feels like a violation of the declared construct (even if it does accord with the declaration in over-the-wire formats).
As a compromise between these different requirements, the approach I've taken here is that, if a property is declared on a schema that's a child of a oneOf, and the property has the same name as the descriminator, then we produce a
def discriminatorPropertyName: String = "expectedValue"
on the child case class. This means that if a case class is the child of two separate oneOfs with the same discriminator name but different values, the generated code will fail; but this feels A) very edge-casey, B) probably bad api design, and C) I can't actually think of a better solution that doesn't have this issue.Example:
Input openapi:
Output scala: