Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#28951 closed Uncategorized (wontfix)

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

Reported by: Stephan Doliov Owned by: nobody
Component: Uncategorized Version: 2.0
Severity: Normal Keywords: loaddata auto_now_add fixtures
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

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?

Change History (2)

comment:1 by Ramiro Morales, 6 years ago

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

comment:2 by Simon Charette, 6 years ago

Resolution: wontfix
Status: newclosed

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.

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