-
-
Notifications
You must be signed in to change notification settings - Fork 7.3k
Fix siblings of $ref using allOf in openapi normalizer #22364
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
Conversation
|
@wing328 You've tested with simple types ( Example: I've tested with the spring generator.
I have a question about the use of allOf. becomes: |
7.4.0 was released a while ago. Are you able to reproduce the issue with v7.17.0? just want to confirm the issue is with this change not earlier stable version v7.17.0 and thanks for testing it. i'll take another look. |
|
Sorry, It is indeed a regression from 7.16.0. |
|
about use of allOf, please refer to https://stackoverflow.com/a/51402417/677735 for more info. We support the openapi 3.0.x way of overriding fields and that's why openapi normalizer normalizes schemas (e.g. 3.1) to conform to this way so that default codegen can handle these schemas with ease. |
No need to sorry and thanks for testing it. |
|
@wing328 the stackoverflow article descibes a nice way to patch an openapi 3,0 contract so that it has features only available in 3.1. The swagger parser does not keep attributes like In this PR you do the opposite. You convert an openapi 3.1 contract to a 3.0 contract while keeping the functionality. It would be nice if the code generation supports the pattern But unfortunately it does not ! I've tested this PR with the spring generator: It generates an Object instead of a String in pre-PR. In the normalizer, there is already a parsed OpenAPI. So the trick is not really needed. |
update normalizer to handle siblings of schema with $ref by converting it to allOf, e.g. normalize
to
Close #20304
PR checklist
Commit all changed files.
This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master.
These must match the expectations made by your contribution.
You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example
./bin/generate-samples.sh bin/configs/java*.IMPORTANT: Do NOT purge/delete any folders/files (e.g. tests) when regenerating the samples as manually written tests may be removed.
master(upcoming7.x.0minor release - breaking changes with fallbacks),8.0.x(breaking changes without fallbacks)"fixes #123"present in the PR description)