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

`allow_unkown` in a nested dict field #1163

Closed
mlshapiro opened this issue Jun 8, 2018 · 3 comments
Closed

`allow_unkown` in a nested dict field #1163

mlshapiro opened this issue Jun 8, 2018 · 3 comments
Labels
bug
Milestone

Comments

@mlshapiro
Copy link

@mlshapiro mlshapiro commented Jun 8, 2018

Note this was originally posted as a stack overflow question

Expected Behavior

We developed a API using Eve 0.7 that used allow_unknown on a nested dict field. This field worked as expected according to the cerberus documentation.

We are now upgrading to Eve 0.8 and our endpoints no longer respect the allow_unknown parameter in nested dicts. I would expect that I can run the example below:

settings.py

DOMAIN = {
    'endpoint': {
        'schema': {
            'data': {
                'type': 'dict',
                'allow_unknown': True,
                'schema': {
                    'prop': {'type': 'string'}
                }
            }
        }
    }
}

RESOURCE_METHODS = ['GET', 'POST', 'DELETE']
ITEM_METHODS = ['GET', 'PATCH', 'PUT', 'DELETE']

app.py

from eve import Eve
app = Eve()
app.run(debug=True)
  • Run the app by running: $ python app.py
  • Test the endpoint with curl:

Pass

$ curl -d '{"data": {"prop": "test prop", "test": 2}}' -H 'Content-Type: application/json'  http://127.0.0.1:5000/endpoint
{"_updated": "Fri, 08 Jun 2018 19:43:11 GMT", "_created": "Fri, 08 Jun 2018 19:43:11 GMT", "_etag": "e04dd19a6e13c74ccdb5561722bb001b0f5dff28", "_id": "5b1adc4f198a2527650320a4", "_links": {"self": {"title": "Endpoint", "href": "endpoint/5b1adc4f198a2527650320a4"}}, "_status": "OK"}

Actual Behavior

  • Run the app by running: $ python app.py
  • Test the endpoint with curl:

Pass

$ curl -d '{"data": {"prop": "test prop"}}' -H 'Content-Type: application/json'  http://127.0.0.1:5000/endpoint
{"_updated": "Fri, 08 Jun 2018 19:43:11 GMT", "_created": "Fri, 08 Jun 2018 19:43:11 GMT", "_etag": "e04dd19a6e13c74ccdb5561722bb001b0f5dff28", "_id": "5b1adc4f198a2527650320a4", "_links": {"self": {"title": "Endpoint", "href": "endpoint/5b1adc4f198a2527650320a4"}}, "_status": "OK"}

Fail (would expect this to pass)

$ curl -d '{"data": {"prop": "test prop", "test": 2}}' -H 'Content-Type: application/json'  http://127.0.0.1:5000/endpoint
{"_status": "ERR", "_issues": {"data": {"test": "unknown field"}}, "_error": {"code": 422, "message": "Insertion failure: 1 document(s) contain(s) error(s)"}}

Environment

  • Python version:
    • Anaconda Python 3.6.4 |Anaconda custom (64-bit)| (default, Jan 16 2018, 12:04:33) [GCC 4.2.1 Compatible Clang 4.0.1 (tags/RELEASE_401/final)] on darwin
  • Eve version: 0.8 (installed via pip install eve)
@mlshapiro
Copy link
Author

@mlshapiro mlshapiro commented Jun 11, 2018

I was able to get my code working again by adding allow_unknown at the resource level. While this solution works, our goal is to allow unknown properties only at a nested level of the schema. This solution allows data to be submitted with unknown properties to any level of the schema.

For a little more context, our API point leverages GeoJSON objects, so we want to enable the properties key to allow unknown keys, but not the top level of the GeoJSON object.

@nicolaiarocci
Copy link
Member

@nicolaiarocci nicolaiarocci commented Jun 11, 2018

Hey there, your SO question caught my eye. Fix coming up Real Soon.

@mlshapiro
Copy link
Author

@mlshapiro mlshapiro commented Jun 11, 2018

Great - Thanks for the help! Really appreciate all the work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants