Fixture loading can fails on second syncdb when auto_now_add field is ommitted

[Russell Keith-Magee]

Via Andrew Turner, on django-users:

Here is a simple initial_data.json:-

[
   {
       "model": "posts.entry",
       "pk": 1,
       "fields": {
           "content": "This is the content"
       }
   }
]

And here is my models.py:-

from django.db import models

class Entry(models.Model):
   content = models.CharField(max_length=250)
   pub_date = models.DateTimeField(auto_now_add=True, editable=False)

First time syncdb is run, the fixture is correctly loaded, subsequent
runs result in the aforementioned error. Tested on Django 1.1.1 and
1.2alpha.

---

Comment by russellm:

The initial syncdb shouldn't be succeeding - for some reason, the field is being populated with a default value generated by the auto_now_add handling. The second syncdb gives the correct error due to the missing pub_date data in the fixture.

[acturneruk]

Repeated syncdbs also succeed (the pub_date field is being populated with a default value) when auto_now=True is used

See ​http://groups.google.com/group/django-users/browse_thread/thread/65fab1fa4104dae6

[Russell Keith-Magee]

Not critical for 1.2

[dmedvinsky]

Not sure if that's the way it should be done, since I don't have a good knowledge of Django guts, but that's how I was able to do what's expected.

[anonymous]

I use auto_now=True and auto_now_add=True for 2 timestamps of respective purpose on all of my models, and I don't have a problem with this. The bug does, however, manifest itself when I accidentally create 2 objects with the same model and PK in a fixture. Upon doing so, any manage.py syncdb will cause an IntegrityError , with a message indicating that one of the timestamp fields can't be null (which is obviously unrelated to the PK issue). I'm not sure what causes this anomaly, but FWIW those steps reproduce the isue.

[Jacob]

Milestone 1.4 deleted

[vsafronovich@…]

The behavoir of 'auto_now_add' was changed in django 1.4 branch (1.4b1), loading fixtures with fields with auto_now_add option now cause an IntegrityError. We use widely fixtures in tests, so many tests was broken. If you removed support of loading fixtures with fields with 'auto_now_add' option, you should generate a DeprecationWarning

[Anssi Kääriäinen]

Could you describe how/why you get the integrity error? Maybe a sample fixture file and the queries generated if possible. +10 points if you can include a test case.

[vsafronovich]

test django 1.4 project to show the testcase

[vsafronovich]

I`v attached the test project with code from the body of this ticket. Try to run tests (manage.py test posts) in django 1.4b1. Tests will broken, but in django 1.3 this tests will passed.

[vsafronovich]

still doesn`t work

[Karen Tracey]

For reasons that are not clear to me, the change in behavior came with r16739 (addition of bulk_create). Prior to that the test in the attached project succeeds, after that it fails due to the fixture failing to load (IntegrityError: posts_entry.pub_date may not be NULL). But from the above discussion it sounds like the "expected" behavior all along was that this fixture would never load correctly due to having a missing required field value? So r16739 "fixed" the unexpectedly-succeeding load of a fixture with non-specified auto_now_add fields...yet that has the side-effect of possibly breaking tests for people who unknowingly were relying on this bug in their test fixtures.

[Preston Holmes]

For reference, further discussion here; ​http://groups.google.com/group/django-users/browse_thread/thread/65fab1fa4104dae6/d9107358d9cb0404

[Preston Holmes]

From discussion at the sprints with Karen, Paul and jezdez, the consensus was that this was in fact fixed by r16739, as Russ implies in the original mail thread that the fact that the fixture loading the first time was a bug.

I've attached a draft release note about this backwards incompatibility.

[Karen Tracey]

In [17694]:

Add a note to the backwards-incompatible changes section of 1.4 release notes about the change related to loading fixtures with incomplete data for auto_now and auto_now_add fields. Refs #12753. Thanks ptone.

[Karen Tracey]

So strictly speaking the bug of the 1st syncdb working for fixtures with missing values for auto_now and auto_now_add fields was fixed by r16739. The backwards-incompatible implicatoins of that fix have now been documented in the release notes (r17694), so I'm closing this ticket as fixed.

[vsafronovich]

Оk, so I need to explicitly set date to some fixed datetime.
What will I do with tests, that tested some objects was created near now time and change behavior for this objects?

I think more you should deprecate using of auto_now and auto_now_add in DateTimeField constructor. And simply add link to wiki, where was described how to set datetime field to now time in save method of the model object.