Opened 15 years ago

Closed 13 years ago

Last modified 13 years ago

#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)

12753.diff (5.1 KB ) - added by dmedvinsky 14 years ago.
test_fixture.zip (5.8 KB ) - added by vsafronovich 13 years ago.
test django 1.4 project to show the testcase
12753-releasenote.diff (939 bytes ) - added by Preston Holmes 13 years ago.

Download all attachments as: .zip

Change History (24)

comment:1 by Russell Keith-Magee, 15 years ago

Triage Stage: UnreviewedAccepted

comment:2 by acturneruk, 15 years ago

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

comment:3 by anonymous, 15 years ago

Cc: bas@… added

comment:4 by Russell Keith-Magee, 15 years ago

milestone: 1.21.3

Not critical for 1.2

comment:5 by dmedvinsky, 14 years ago

Owner: changed from nobody to dmedvinsky

by dmedvinsky, 14 years ago

Attachment: 12753.diff added

comment:6 by dmedvinsky, 14 years ago

Has patch: set

comment:7 by dmedvinsky, 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 Matt McClanahan, 14 years ago

milestone: 1.31.4
Severity: Normal
Type: Bug

comment:9 by anonymous, 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:10 by Jacob, 13 years ago

milestone: 1.4

Milestone 1.4 deleted

comment:11 by vsafronovich@…, 13 years ago

Version: 1.11.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 Anssi Kääriäinen, 13 years ago

Cc: anssi.kaariainen@… 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.

by vsafronovich, 13 years ago

Attachment: test_fixture.zip added

test django 1.4 project to show the testcase

comment:13 by vsafronovich, 13 years ago

Cc: vsafronovich 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:14 by vsafronovich, 13 years ago

Severity: NormalRelease blocker

still doesn`t work

comment:15 by Karen Tracey, 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.

by Preston Holmes, 13 years ago

Attachment: 12753-releasenote.diff added

comment:17 by Preston Holmes, 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:18 by Karen Tracey, 13 years ago

Owner: changed from dmedvinsky to Karen Tracey


comment:19 by Karen Tracey, 13 years ago

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.

comment:20 by Karen Tracey, 13 years ago

Resolution: fixed
Status: newclosed

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.

comment:21 by vsafronovich, 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.

Version 0, edited 13 years ago by vsafronovich (next)
Note: See TracTickets for help on using tickets.
Back to Top