Skip to content
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

Why doesn't Marshmallow Dict field resolve to additionalProperties? #201

Closed
UrKr opened this issue May 4, 2018 · 4 comments

Comments

@UrKr
Copy link
Contributor

commented May 4, 2018

Any Dict field in a schema seems to resolve to just 'type': 'object' in the spec output. Why not to additionalProperties?


class ASchema(MM.Schema):
    data = MM.fields.Dict(keys=MM.fields.String(), values=MM.fields.Nested(OtherSchema), required=True)

the yaml output for:
spec.definition('A', ASchema, schema=ASchema)
is this:
data: {type: object}
Why not this:

data: {
  type: object,
  additionalProperties: {
    $ref: '#/definitions/A'
  }
}
@lafrech

This comment has been minimized.

Copy link
Member

commented May 4, 2018

keys and values were added in marshmallow 3 and are not yet documented by apispec. Indeed, it would be nice to have them documented.

Not sure how that would look like, though.

(Thinking out loud.) In marshmallow, keys can be anything, including stuff that would generate wrong JSON. (I mean can you use arrays as dict indexes in JSON? I guess not.) It is fine if we ignore pathological cases. I mean if the doc feature does not work on cases that can't be functional anyway, no big deal.

@UrKr

This comment has been minimized.

Copy link
Contributor Author

commented May 4, 2018

Yes, I suppose it would only have to work with string keys. Though the keys value could actually just be ignored, no?

Are you taking pull requests for this? I don't have one ready or anything, I would have to look at the code and see what I can do. Is there any other ambiguity apart from the keys? Naively, I would think it's just a matter of adding additional Dict field handling.

@lafrech

This comment has been minimized.

Copy link
Member

commented May 4, 2018

Yes, I suppose we can ignore keys.

We welcome PRs. When the change involved is a bit tricky, it can be better to discuss it here before actually working on it, to avoid the frustration of seeing the PR not merged.

From this SO post, it seems your fix is correct, so it's simpler than I thought. You can send a PR implementing this.

Thanks!

@lafrech

This comment has been minimized.

Copy link
Member

commented May 7, 2018

Fixed in #202.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.