#12753 closed Bug (fixed)
Fixture loading can fails on second syncdb when auto_now_add field is ommitted
Reported by: | Russell Keith-Magee | Owned by: | Karen Tracey |
---|---|---|---|
Component: | Core (Serialization) | Version: | 1.4-beta-1 |
Severity: | Release blocker | Keywords: | |
Cc: | bas@…, anssi.kaariainen@…, vsafronovich | Triage Stage: | Accepted |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
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.
Attachments (3)
Change History (24)
comment:1 by , 15 years ago
Triage Stage: | Unreviewed → Accepted |
---|
comment:2 by , 15 years ago
comment:3 by , 15 years ago
Cc: | added |
---|
comment:5 by , 14 years ago
Owner: | changed from | to
---|
by , 14 years ago
Attachment: | 12753.diff added |
---|
comment:6 by , 14 years ago
Has patch: | set |
---|
comment:7 by , 14 years ago
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.
comment:8 by , 14 years ago
milestone: | 1.3 → 1.4 |
---|---|
Severity: | → Normal |
Type: | → Bug |
comment:9 by , 13 years ago
Easy pickings: | unset |
---|---|
UI/UX: | unset |
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.
comment:11 by , 13 years ago
Version: | 1.1 → 1.4-beta-1 |
---|
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
comment:12 by , 13 years ago
Cc: | added |
---|
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.
comment:13 by , 13 years ago
Cc: | added |
---|
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.
comment:15 by , 13 years ago
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.
comment:16 by , 13 years ago
For reference, further discussion here; http://groups.google.com/group/django-users/browse_thread/thread/65fab1fa4104dae6/d9107358d9cb0404
by , 13 years ago
Attachment: | 12753-releasenote.diff added |
---|
comment:17 by , 13 years ago
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.
comment:20 by , 13 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:21 by , 13 years ago
Оk, so I need to explicitly set date to some fixed time.
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 in save
method of the model object.
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