Opened 5 years ago

Closed 3 years ago

Last modified 3 years ago

#12753 closed Bug (fixed)

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

Reported by: russellm Owned by: kmtracey
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


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

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

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 4 years ago. (5.8 KB) - added by vsafronovich 3 years ago.
test django 1.4 project to show the testcase
12753-releasenote.diff (939 bytes) - added by ptone 3 years ago.

Download all attachments as: .zip

Change History (24)

comment:1 Changed 5 years ago by russellm

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Accepted

comment:2 Changed 5 years ago by acturneruk

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


comment:3 Changed 5 years ago by anonymous

  • Cc bas@… added

comment:4 Changed 5 years ago by russellm

  • milestone changed from 1.2 to 1.3

Not critical for 1.2

comment:5 Changed 4 years ago by dmedvinsky

  • Owner changed from nobody to dmedvinsky

Changed 4 years ago by dmedvinsky

comment:6 Changed 4 years ago by dmedvinsky

  • Has patch set

comment:7 Changed 4 years ago by 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.

comment:8 Changed 4 years ago by mattmcc

  • milestone changed from 1.3 to 1.4
  • Severity set to Normal
  • Type set to Bug

comment:9 Changed 4 years ago by anonymous

  • 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 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 Changed 4 years ago by jacob

  • milestone 1.4 deleted

Milestone 1.4 deleted

comment:11 Changed 3 years ago by vsafronovich@…

  • Version changed from 1.1 to 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 Changed 3 years ago by akaariai

  • 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.

Changed 3 years ago by vsafronovich

test django 1.4 project to show the testcase

comment:13 Changed 3 years ago by vsafronovich

  • Cc vsafronovich added

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

comment:14 Changed 3 years ago by vsafronovich

  • Severity changed from Normal to Release blocker

still doesn`t work

comment:15 Changed 3 years ago by kmtracey

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.

Changed 3 years ago by ptone

comment:17 Changed 3 years ago by ptone

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 Changed 3 years ago by kmtracey

  • Owner changed from dmedvinsky to kmtracey

comment:19 Changed 3 years ago by kmtracey

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 Changed 3 years ago by kmtracey

  • Resolution set to fixed
  • Status changed from new to closed

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 Changed 3 years ago by 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.

Last edited 3 years ago by vsafronovich (previous) (diff)
Note: See TracTickets for help on using tickets.
Back to Top