loaddata from fixture doesn't work with null=False auto_now_add fields

[Stephan Doliov]

for a model

from django.db import models

class Foo(models.Model):
    name = models.TextField(max_length=256,null=False)
    created = models.DateTimeField(auto_now_add=True,null=False)

and a fixture file foo_data.json

[
    {
        "model": "app.Foo",
        "pk": 1,
        "fields": {
            "name": "Foo is fun"
        }
    }
]

./manage.py load_data fixtures/foo_data.json

fails, as expected because the fixture is loaded as raw.

This is annoying however to mock up a fixture file (especially a long one used for exercising hundreds of test cases) with manufactured timestamps.

What are the benefits/drawbacks of modifying the loaddata routine to respect the creation of auto_now_add values, and possibly auto_now values?

[Ramiro Morales]

IMHO, the most predictable choice would be to actually provide the Foo.created values in your fixture file.

I don't think it would be correct nor practical to make loaddata smart about this because it could open the door to more choices: e.g. What value should it set when faced with fixture files like:

• say, 1000 Foo's. Should it set one unique timestamp for every Foo? Should it set 1000 different values set apart for a few miliseconds?
• What if Foo has more than one DateTimeField with auto_now_add=True?
• What if it includes instances of more than one model with a DateTimeField field with auto_now_add=True?

One choice Django makes here would cater for some use cases bot not for others. Then it's possible we would receive requests to make the smart behavior customizable from the command line, ...

Another option is to use tools like factory_boy

[Simon Charette]

I agree with Ramiro.

Using fixtures to provide initial data for tests has always been fragile with regards to schema migrations and trying to be smart for auto_now here would pave the way to a slippery slope.