Skip to content

Conversation

@noirbizarre
Copy link
Collaborator

This pull request try to fix #934 by adding an optionnal meta attribute: strict.

This attribute disable field existence check on data load, but not on constructor calls.

It also document both behaviors.

Review on Reviewable

@landscape-bot
Copy link

Code Health
Code quality remained the same when pulling ddbcc8e on noirbizarre:metastrict into 19dc312 on MongoEngine:master.

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.0%) to 73.02% when pulling ddbcc8e on noirbizarre:metastrict into 19dc312 on MongoEngine:master.

@landscape-bot
Copy link

Code Health
Code quality remained the same when pulling 52c7b68 on noirbizarre:metastrict into 19dc312 on MongoEngine:master.

@gordol
Copy link

gordol commented Apr 13, 2015

Why a duplicate fix for the same issue?

Check my pull request over here: https://github.com/MongoEngine/mongoengine/pull/953/files#diff-e3e316e6686a3db66d2e679634f57f7f

I think you might need to refactor a bit... This test fails on your branch:

    def test_undefined_field_allowed_read(self):
        """
        Test read from data wtih undefined fields #934 #953
        """

        class A(Document):
            test = StringField(required=True)
            test2 = StringField(required=True)
            meta = {'collection': 'undefined_test'}

        class B(Document):
            test = StringField(required=True)
            meta = {'collection': 'undefined_test', 'strict': True}

        a = A()
        a.test = 'one'
        a.test2 = 'two'
        a.save()

        try:
            b = B.objects.get()
            self.assertEqual(b.test, a.test)
        except Exception:
            self.fail()

@gordol
Copy link

gordol commented Apr 13, 2015

Oh wait, nevermind... I see what you did. B() meta should set strict to False, my mistake. I pulled the test from my branch and replaced 'ignore_undefined_fields' with 'strict', not thinking about the logic being inverse.

@noirbizarre
Copy link
Collaborator Author

I submit the pull-request because I started it before you submitted yours and before I saw the discussion.
Both solutions are a little bit differents so I submitted mine too.

Feel free to pick some code or documentation.
The only thing that matter to me is that there is a proper fix and both behaviors are specified and documented.

Yeah, you should set strict to False if you want to load some unspecified fields.
The constructor is always checked, even with strict set to False.

By the way, you should avoid the following pattern:

try:
    # do whatever raises an exception
except Exception:
    self.fail()

Simply let the exception be catched by the testing framework.
It will have the same effect but the stacktrace wil be way more useful.

@gordol
Copy link

gordol commented Apr 13, 2015

Simply let the exception be catched by the testing framework.
It will have the same effect but the stacktrace will be way more useful.

Indeed.

Thanks.

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.0%) to 73.02% when pulling 52c7b68 on noirbizarre:metastrict into 19dc312 on MongoEngine:master.

5 similar comments
@coveralls
Copy link

Coverage Status

Coverage decreased (-0.0%) to 73.02% when pulling 52c7b68 on noirbizarre:metastrict into 19dc312 on MongoEngine:master.

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.0%) to 73.02% when pulling 52c7b68 on noirbizarre:metastrict into 19dc312 on MongoEngine:master.

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.0%) to 73.02% when pulling 52c7b68 on noirbizarre:metastrict into 19dc312 on MongoEngine:master.

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.0%) to 73.02% when pulling 52c7b68 on noirbizarre:metastrict into 19dc312 on MongoEngine:master.

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.0%) to 73.02% when pulling 52c7b68 on noirbizarre:metastrict into 19dc312 on MongoEngine:master.

@mmellison
Copy link
Contributor

I can definitely get behind this PR but I think there needs to be a discussion around this when we get ready to bump up to the next major version (0.10 or 1.0).

On the other side, using a dynamic model saves the extra attributes in DB and prevent to use temporary/client-side only attributes (a little bit sad when using Python) -- @noirbizarre

Thanks for the counter-example, this makes things more clear now! I still think there are some client side workarounds but I think it would be easier for both us the maintainers and users to add this option in for now and re-evaluate our options in the future.

@noirbizarre
Copy link
Collaborator Author

Great !

@mmellison
Copy link
Contributor

+1

@gordol
Copy link

gordol commented Apr 28, 2015

👍 😜

@MRigal
Copy link
Member

MRigal commented Apr 29, 2015

👍 I am actually in favour of stricter validation, but this one seems to have impacted enough people !

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

Successfully merging this pull request may close these issues.

#457 breaks legacy/undeclared fields

8 participants