Skip to content

Fails to unmarshall free-form objects (additionalProperties) #153

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

Closed
pcrespov opened this issue Aug 13, 2019 · 3 comments
Closed

Fails to unmarshall free-form objects (additionalProperties) #153

pcrespov opened this issue Aug 13, 2019 · 3 comments

Comments

@pcrespov
Copy link

Current version can validate free-form objects but cannot unmarshall them.

A free-form object (arbitrary property/value pairs) is defined equivalently see reference as

type: object

or

type: object
additionalProperties: true

or

type: object
additionalProperties: {}

PR #121 address a related issue that solves validation but still unable to unmarshall. For instance, the example proposed by @berend in the same pull request cannot be unmarshalled as demonstrated in a tests I did in my fork

Any hint on how to overcome/fix this?

@pcrespov pcrespov changed the title Fails to unmarshall free-form objects Fails to unmarshall free-form objects (additionalProperties) Aug 13, 2019
@pcrespov
Copy link
Author

Any hint on how to overcome this?

@playpauseandstop
Copy link

Hi,

While working on adding OpenAPI 3 support for aiohttp.web applications I ran into same issue.

I managed to fix it ugly by merging casted data into unmarshaled data, but I wonder maybe there are plans on support free-form objects in openapi-core?


I understand that Model class based on top of list of schema properties, but there should be an exception for next OpenAPI 3 schema,

  type: "object"
  additionalProperties: true

And even more. As additionalProperties is true by default,

additionalProperties - Value can be boolean or object. Inline or referenced schema MUST be of a Schema Object and not a standard JSON Schema. Consistent with JSON Schema, additionalProperties defaults to true.

maybe it is needed to redesign Model to support, by default, any properties sent to the object and only in case of,

  type: "object"
  properties:
    one:
       type: "string"
    two:
       type: "string"
  additionalProperties: false

enforce current behavior?

@p1c2u
Copy link
Collaborator

p1c2u commented Feb 3, 2020

After rework of unmarshalling process I believe the issue finally can be fixed. Thank you all for your contribution.

@p1c2u p1c2u closed this as completed Feb 3, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants