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

FieldTracker failing with Django 1.10 #232

Closed
jarekwg opened this issue Aug 12, 2016 · 2 comments

Comments

@jarekwg
Copy link
Contributor

commented Aug 12, 2016

I know you're already aware the dj110 tests don't pass, but thought I'd leave an open ticket for this, with (hopefully relevant) info I've come across.

I might also have a go at tackling this over the weekend, but no promises. ;)

So my issue since upgrading to dj110 and updating to model-utils 2.5.1:
Creating a model instance via a DjangoModelFactory (in my case using factory-boy), causes the initialised fields to come up on the FieldTracker as having changed in successive saves. DjangoModelFactory() calls the model's .save() method up to three times in some cases, so with this bug, a post_save handler will think the field has changed numerous times and will register fields as having changed multiple times, instead of not mentioning anything since the fields were set on init. This appears to happen both with FK fields and regular ones, so no discrimination there. factory-boy hasn't changed recently, so I suspect the problem lies with model-utils' FieldTracker, but I might be wrong.

@jarekwg

This comment has been minimized.

Copy link
Contributor Author

commented Aug 14, 2016

So after a bit of digging, it seems dj110 is marking all model fields as deferred by default..

ie instance._deferred_fields seems to now contain a list of all the model fields when in the past it was just [].

Will keep digging.

e: from d110 patch notes:

Model.__init__() now receives django.db.models.DEFERRED as the value of deferred fields.

Hrm.

e2: Okay so it's actually model-utils thinking that the fields are deferred because it checks for instance._deferred, which no longer exists.

@brianmay

This comment has been minimized.

Copy link

commented Sep 11, 2016

Any chance of a new release with this fixed?

Thanks

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.