-
-
Notifications
You must be signed in to change notification settings - Fork 186
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
fix: oneof implementation #814
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Welcome to AsyncAPI. Thanks a lot for creating your first pull request. Please check out our contributors guide useful for opening a pull request.
Keep in mind there are also other channels you can use to interact with AsyncAPI community. For more details check out this issue.
Kudos, SonarCloud Quality Gate passed! 0 Bugs No Coverage information |
Pull Request Test Coverage Report for Build 2677437607
💛 - Coveralls |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @jacopomaroli, thanks for providing this!
I really dont want to change what's currently on the master branch, because this change is really difficult to do right in that environment.
Do you have the possibility to recreate it and target next
?
I can guide you through the change it require 🙂
Fixed in |
Description
Currently oneOf and anyOf are treated equally
modelina/src/interpreter/Interpreter.ts
Lines 85 to 86 in 7a23949
This PR aims to handle correctly oneOf in accordance to the OpenAPI specs https://swagger.io/docs/specification/data-models/oneof-anyof-allof-not/#anyof-vs-oneof
I needed to update one of the tests because there's no reason for oneOf to generate an array type implicitly in the datamodel definition
Related issue(s)
Fixes #367