Problems with contenttypes when loading a device in Django

Question

I am having trouble loading Django into my MySQL database due to content type conflicts. At first, I tried to dump data only from my application as follows:

./manage.py dumpdata escola > fixture.json 

but I kept getting the missing external issues because my escola application uses tables from other applications. I continued to add additional applications until I got to this:

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

Now the problem is the following violation of restrictions when trying to load data as a test device:

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

The problem seems to be that Django is trying to dynamically recreate content types with different primary key values ​​that contradict the primary key values ​​from the device. This is similar to the error described here: http://code.djangoproject.com/ticket/7052

The problem is that the recommended solution is to reset the contenttypes application, which I already do !? What gives? If this makes any difference, I have some user model permissions, as described here: http://docs.djangoproject.com/en/dev/ref/models/options/#permissions

Answer 1

manage.py dumpdata --natural will use a longer representation of foreign keys. In django, they are called "natural keys." For example:

• Permission.codename used in favor of Permission.id
• User.username used in favor of User.id

Read more: natural keys section in "django object serialization"

Some other useful arguments for dumpdata :

• --indent=4 make it understandable to humans.
• -e sessions exclude session data
• -e admin exclude the history of the administrator’s actions on the administrator’s site.
• -e contenttypes -e auth.Permission exclude objects that are automatically recreated from the schema every time during syncdb . Use it only with --natural , otherwise you may encounter poorly aligned identifier numbers.

Answer 2

Yes, it is really annoying. For some time I worked on it, performing "manage.py reset" in the contenttypes application before loading the device (in order to get rid of automatically generated content data that was different from the reset version). It worked, but in the end I got tired of the troubles and abandoned fixtures completely in favor of direct SQL dumps (of course, then you lose DB portability).

update is the best answer - use the --natural flag for dumpdata , as indicated in the answer below. This flag did not exist when I wrote this answer.

Answer 3

Try skipping content types when creating the binding:

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

This worked for me in a similar situation for unit tests, understanding about content types really helped you!

Answer 4

The answers here are all old ... As of 2017, the best answer is:

 manage.py dumpdata --natural-foreign --natural-primary -e contenttypes -e auth.Permission --indent 4 

Answer 5

I did not use MySQL, but instead imported some data from a live server into sqlite. Clearing the contenttypes application contenttypes before doing loaddata did the trick:

 from django.contrib.contenttypes.models import ContentType ContentType.objects.all().delete() quit() 

And then

 python manage.py loaddata data.json 

Answer 6

I solved this problem in my test cases by dropping the contenttypes application from unit test before loading the dump file. Karl suggested this already with the manage.py command, and I do the same only with 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 a content application dump that matches the rest of the test data. By dumping the application before downloading, it prevents duplication of the IntegrityError key.

Answer 7

 python manage.py dumpdata --natural-primary --exclude=contenttypes --exclude=auth.Permission --exclude=admin.logentry --exclude=sessions.session --indent 4 > initial_data.json 

This works for me. Here I exclude all the bubbles of real models.

• If you see any other model other than the models you created, you can safely exclude them. One of the drawbacks of this approach is that you lose log data as well as auth data.

Answer 8

You must use natural keys to represent any foreign key and many-to-many relationship. Also, it might be a good idea to exclude the session table in the sessions application and the logentry table in the admin application.

Django 1.7+

 python manage.py dumpdata --natural-foreign --exclude contenttypes --exclude auth.permission --exclude admin.logentry --exclude sessions.session --indent 4 > fixture.json 

Django <1.7

 python manage.py dumpdata --natural --exclude contenttypes --exclude auth.permission --exclude admin.logentry --exclude sessions.session --indent 4 > fixture.json 

According to Django's documentation , --natural deprecated in version 1.7, so use the --natural-foreign option --natural-foreign .

You can also omit the primary key in the serialized data of this object, since it can be computed during deserialization by passing the --natural-primary flag.

 python manage.py dumpdata --natural-foreign --natural-primary --exclude contenttypes --exclude auth.permission --exclude admin.logentry --exclude sessions.session --indent 4 > fixture.json 

Answer 9

 ./manage.py dumpdata app.Model --natural-foreign 

will change

  "content_type": 123 

at

  "content_type": [ "app_label", "model" ], 

And the mount works for TestCase now

Answer 10

I am going to give another possible answer that I just realized. Maybe this will help the OP, maybe it will help someone else.

I have a many-to-many relationship table. It has a primary key and two foreign keys to other tables. I found that if I have an entry in the device that have two foreign keys matching another entry already in the table with a different pk, this will not work. M2M relationship tables have a “unique combination” for two foreign keys.

So, if this is a violation of the M2M relationship, look at the foreign keys that it adds, look at your database to see that this FK pair is already listed in different PKs.

Answer 11

It's really, really annoying .. I bite it every time.

I tried creating dumpdata with --exclude contenttypes and - naturally, I always get problems.

What works best for me, just do truncate table django_content_type; after syncdb and THEN load the data.

Of course, for autoload initial_data.json you are a fallball.

Answer 12

I sometimes came across a similar error. It turned out that I was trying to load devices before creating the necessary tables. So I did:

 $ python manage.py makemigrations $ python manage.py migrate $ python manage.py loaddata fixtures/initial_data.json 

And he worked like a charm