-
Notifications
You must be signed in to change notification settings - Fork 2.2k
How to prevent oneOf() on supertypes leading to recursion in subtypes? #3677
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
@ckaag Have you found any solution? |
I have managed to do it with some util that flattens and removes Util code:
And then use it: If your schema contains nested allOf schemas, you will need to rewrite that code to recursively go through allOf schemas and get all properties, it should not be hard. I have added custom exception for that code to be able to test my API against such case and for my case it's not needed. I have tested it on quite big API and it works. Also I had to add |
While debugging an issue on Javalin's OpenAPI plugin ( javalin/javalin#1032 ) I found following behavior inside swagger-core at the following line:
https://github.com/swagger-api/swagger-core/blob/v2.1.2/modules/swagger-core/src/main/java/io/swagger/v3/core/jackson/ModelResolver.java#L1306
My scenario is as follows:
S
of both subtypesA
andB
.@Schema(oneOf = {A.class, B.class})
onS
.This will end up with
S
getting the oneOf-Attribute as requested BUT bothA
andB
thanks to this line getallOf = {S.class}
assigned by the ModelResolver. As far as I understand this is to deal with inheritance.The result of this from an API perspective: if
S
is specified, the value may beA
orB
. ButA
is allOf(S), so transitively it's alsooneOf(A, B)
. While in this isolated example, this is still fine, because the specific types are transparent if they're only ever used asS
. But assumeA
is also reused somewhere else in the API specification: in this case the resulting Schema object would allow you to replaceA
withallOf(A, B)
which seems to be not precise (at least in languages that aren't dynamically- or duck-typed).Where did my thinking in this use case go wrong?
Or to ask the question on a higher abstraction: How can I structure my input to the ModelResolver using
oneOf
designation on the superclass without this recursive specification result on the subclass?Thanks for any input on this!
The text was updated successfully, but these errors were encountered: