Initial data fixtures and auto_now_add=True
Andrew Turner
whenever I run syncdb. One of my models has a DateTimeField with
auto_now_add=True. The data is loaded first time round, but on
subsequent syncdbs, I get "IntegrityError: posts_entry.pub_date may
not be NULL".
Is this the expected behaviour? Note that all is fine if the field is
changed to auto_now=True instead.
Andrew Turner
> I have an initial_data.json file which provides some, er, initial data
> whenever I run syncdb. One of my models has a DateTimeField with
> auto_now_add=True. The data is loaded first time round, but on
> subsequent syncdbs, I get "IntegrityError: posts_entry.pub_date may
> not be NULL".
Anyone? Is this behaviour expected, or should I file a bug?
Russell Keith-Magee
Well, it's difficult to know what is expected without more details. I
can't think of any obvious reason why a fixture should fail on the
*second* syncdb that doesn't also involve you doing something
unexpected to your data in the interim. However, without any details
of what else is in your models, or what else you have done to your
data, it's impossible to say if you've found a bug or if you're doing
something wrong.
It is possible you've found a bug, but in order to verify that, we
need a minimal example that reproduces the problem - that is, the
simplest possible model and fixture combination that fails on the
second syncdb like you describe.
Yours,
Russ Magee %-)
Andrew Turner
> It is possible you've found a bug, but in order to verify that, we
> need a minimal example that reproduces the problem - that is, the
> simplest possible model and fixture combination that fails on the
> second syncdb like you describe.
Thanks for the reply.
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.
Thanks,
Andrew
Russell Keith-Magee
It appears you have found a bug (what is worse - one that I thought we
were testing for).
The cause of the problem is your initial fixture. Django doesn't
listen to auto_now_add or auto_now fields on fixture loading - fixture
objects are saved in "raw" mode, so it is assumed that the fixture
should have data for all the fields. In this case, your fixture is
missing a definition for pub_date, so on the second sync, you are
getting the error I would expect - that the null value in the column
isn't allowed.
However, you should also be getting that error on the first syncdb.
For some reason, the raw mode save isn't preventing the default value
from being initialized. This is a bug, which I've opened as #12753.
Of course, the immediate workaround for you is to include a datetime
in your fixture.
Yours,
Russ Magee %-)
Andrew Turner
> The cause of the problem is your initial fixture. Django doesn't
> listen to auto_now_add or auto_now fields on fixture loading - fixture
> objects are saved in "raw" mode, so it is assumed that the fixture
> should have data for all the fields. In this case, your fixture is
> missing a definition for pub_date, so on the second sync, you are
> getting the error I would expect - that the null value in the column
> isn't allowed.
I see. As stated in my original post, syncdb works the second time
round when auto_now=True is used. Surely that shouldn't work at all
either?
Russell Keith-Magee
Correct. I'm guessing that the same thing is happening - the default
value is being used because the fixture doesn't specify a value. Feel
free to update the ticket so the auto_now case isn't forgotten.
Yours,
Russ Magee %-)
Andrew Turner
> Correct. I'm guessing that the same thing is happening - the default
> value is being used because the fixture doesn't specify a value. Feel
> free to update the ticket so the auto_now case isn't forgotten.
Done ;)
Kind regards,
Andrew