-
Notifications
You must be signed in to change notification settings - Fork 190
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
Casting of additionalProperties #359
Comments
zoten
pushed a commit
to zoten/open_api_spex
that referenced
this issue
May 5, 2021
zoten
pushed a commit
to zoten/open_api_spex
that referenced
this issue
May 6, 2021
zoten
pushed a commit
to zoten/open_api_spex
that referenced
this issue
May 6, 2021
zoten
pushed a commit
to zoten/open_api_spex
that referenced
this issue
May 6, 2021
Merged
zoten
pushed a commit
to zoten/open_api_spex
that referenced
this issue
May 7, 2021
moxley
pushed a commit
that referenced
this issue
May 8, 2021
* tests to clarify behaviour of additionalProperties keys * Correctly decode additionalProperties with references (#359) Co-authored-by: Luca Dei Zotti <luca.deizotti@athonet.com>
Resolved in #360 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Here I come again :)
But this time at least with a PR and some other questions :)
I noticed that additionalProperties seem not to be parsed properly if they are refs, when loading spec from a file.
In particular, they are not cast-ed to %Reference struct, but they remain maps, which causes later a Cast failure.
The PR addresses this issue. It was also possible to allow cast.ex to resolve maps containing $ref key, but seemed dirty, so I preferred modifying decode.
I also added a stub of yaml test, that adds an optional dependency. If this is unwanted I can of course go back to json-only.
The commit on top of the PR instead shows two failing tests that reveal a behaviour that I don't know if is wanted: when casting additional properties, keys are not converted to atoms. I think this is pretty fine, since the referenced value is correctly cast-ed, just wanted to point this out :)
Thanks, as always, for the great work! Hoping to come back with contributions for the previous issues sooner or later
The text was updated successfully, but these errors were encountered: