views:

1039

answers:

4

I am having trouble loading Django fixtures into my MySQL database because of contenttypes conflicts. First I tried dumping the data from only my app like this:

./manage.py dumpdata escola > fixture.json

but I kept getting missing foreign key problems, because my app "escola" uses tables from other applications. I kept adding additional apps until I got to this:

./manage.py dumpdata contenttypes auth escola > fixture.json

Now the problem is the following constraint violation when I try to load the data as a test fixture:

IntegrityError: (1062, "Duplicate entry 'escola-t23aluno' for key 2")

It seems the problem is that Django is trying to dynamically recreate contenttypes with different primary key values that conflict with the primary key values from the fixture. This appears to be the same as bug documented here: http://code.djangoproject.com/ticket/7052

The problem is that the recommended workaround is to dump the contenttypes app which I'm already doing!? What gives? If it makes any difference I do have some custom model permissions as documented here: http://docs.djangoproject.com/en/dev/ref/models/options/#permissions

+8  A: 

Yes, this is really irritating. For a while I worked around it by doing a "manage.py reset" on the contenttypes app prior to loading the fixture (to get rid of the automatically-generated contenttypes data that differed from the dumped version). That worked, but eventually I got sick of the hassles and abandoned fixtures entirely in favor of straight SQL dumps (of course, then you lose DB portability).

Carl Meyer
I was running into this too, resetting the contenttypes app worked for me as well. Thanks for the tip!
Beau
How did you reset them? In test case class? Give me an example please
Oleg Tarasenko
I don't use fixtures for unittests, I generally create test data using the ORM in a setup() method because it's easier to keep in sync with the tests. So I never had to do this in a TestCase class, though I'm sure if you poke around in the code for Django's TestCase class you could figure out how to make a reset happen post syncdb and prior to fixture loading in a subclass. For me it was just "./manage.py reset contenttypes" in a bash script prior to "./manage.py loaddata my_fixture".
Carl Meyer
This works great! Thanks.
Brandon Craig Rhodes
+2  A: 

Try skipping contenttypes when creating fixture:

./manage.py dumpdata --exclude contenttypes > fixture.json

It worked for me in a similar situation for unit tests, your insight regarding the contenttypes really helped!

Evgeny
A: 

I have resolved this issue in my test cases by resetting the contenttypes app from the unit test prior to loading my dump file. Carl suggested this already using the manage.py command and I do the same thing only using the call_command method:

>>> from django.core import management
>>> management.call_command("flush", verbosity=0, interactive=False)
>>> management.call_command("reset", "contenttypes", verbosity=0, interactive=False)
>>> management.call_command("loaddata", "full_test_data.json", verbosity=0)

My full_test_data.json fixture contains the contenttypes app dump that corresponds to the rest of the test data. By resetting the app before loading, it prevents the duplicate key IntegrityError.

jdl2003