[Fixed]-ContentType matching query does not exist

I’m surprised no one mentioned the fact that fixture is a list that is being read from first value to last. And it’s often possible that there will be a row that mentions a Primary key of a table that will be added latter.

such mistake (generating this extact issue) would look like this in a fixture:

{"model": "lesson", "fields": {"class": 1}},
{
  "model": "class",
  "pk": 1
}

from above example you can see that <Model> matching query query doesn't exist (lesson cannot be added because class with pk=1 has not been added yet).
So you have to add classes before you can have lessons, so just switch them up in a fixture.

You can check manually every ContentType table in your db or:

• If your tables are empty, deletes the tables of your models in your db et re-run syncdb (only if your in development)

Or you can use one of the Django migration tools:

• the accessible django-evolution

• Or the more complex south

In some cases, this error is caused when your fixture contains references to a model that doesn’t exist, either because it hasn’t been installed or its app hasn’t been added your your INSTALLED_APPS. Unfortunately, Django’s error message is pretty useless when tracking this down.

If you edit the Queryset.get method in django/db/models/query.py to print out the *args and **kwargs passed, you’ll get a more helpful error message like:

DeserializationError: Problem installing fixture ... ContentType matching query does not exist. args=() kwargs={'model': u'somenewmodel', 'app_label': u'somenewapp'}

Then you can check that this model/app is installed or remove those records from your fixture.

This is what worked for me after a lot of trials. I was having a lot of trouble with groups and logs.

• While on sqllite, start server, go to admin and delete all groups. Then type the following in shell:

  python manage.py dumpdata –natural-foreign –natural-primary -e
  contenttypes -e auth.Permission -e admin.Logentry > datadump_3.json

• Change settings to MySQL in settings.py

• python manage.py loaddata datadump_3.json

I found a different cause for this error, I wanted to add in case this helps anyone else. What was causing this issue for me is that I had created a group with specific permissions, and then uninstalled an app that was referenced in the group.

Specifically, I had installed reversion at one point, and created a group called “Site Editor” that gave a user permission to create, edit and delete revisions. Later I un-installed revision, but the group permissions remained when I ran the “dumpdata” command:

[
{
    "fields": {
        "name": "Site Editor",
        "permissions": [
            [
                "add_logentry",
                "admin",
                "logentry"
            ],
            [
                "change_logentry",
                "admin",
                "logentry"
            ],
            [
                "delete_logentry",
                "admin",
                "logentry"
            ],
            [
                "add_group",
                "auth",
                "group"
            ],
            [
                "change_group",
                "auth",
                "group"
            ],
            [
                "delete_group",
                "auth",
                "group"
            ],
            [
                "add_revision",
                "reversion",
                "revision"
            ],
            [
                "change_revision",
                "reversion",
                "revision"
            ],
            [
                "delete_revision",
                "reversion",
                "revision"
            ],
            [
                "add_version",
                "reversion",
                "version"
            ],
            [
                "change_version",
                "reversion",
                "version"
            ],
            [
                "delete_version",
                "reversion",
                "version"
            ],
            [
                "add_session",
                "sessions",
                "session"
            ],
            [
                "change_session",
                "sessions",
                "session"
            ],
            [
                "delete_session",
                "sessions",
                "session"
            ],
            [
                "add_site",
                "sites",
                "site"
            ],
            [
                "change_site",
                "sites",
                "site"
            ],
            [
                "delete_site",
                "sites",
                "site"
            ]
        ]
    },
    "model": "auth.group",
    "pk": 2
}]

When I attempted to run the “loaddata” command, I kept running into this error:

django.core.serializers.base.DeserializationError: 
Problem installing fixture '/Users/me/Documents/Sites/project/path/fixtures/configuration.json': 
ContentType matching query does not exist.

My solution was to simply remove any reference to reversion and versions in the fixture itself, like so:

    [
{
    "fields": {
        "name": "Site Editor",
        "permissions": [
            [
                "add_logentry",
                "admin",
                "logentry"
            ],
            [
                "change_logentry",
                "admin",
                "logentry"
            ],
            [
                "delete_logentry",
                "admin",
                "logentry"
            ],
            [
                "add_group",
                "auth",
                "group"
            ],
            [
                "change_group",
                "auth",
                "group"
            ],
            [
                "delete_group",
                "auth",
                "group"
            ],
            [
                "add_session",
                "sessions",
                "session"
            ],
            [
                "change_session",
                "sessions",
                "session"
            ],
            [
                "delete_session",
                "sessions",
                "session"
            ],
            [
                "add_site",
                "sites",
                "site"
            ],
            [
                "change_site",
                "sites",
                "site"
            ],
            [
                "delete_site",
                "sites",
                "site"
            ]
        ]
    },
    "model": "auth.group",
    "pk": 2
}]

Then I was able to import the fixture without issue.

From django 1.7, dumpdata options have changed:
see http://polarhome.com:753/doc/python-django-doc/html/topics/serialization.html

So you an use:

python manage.py dumpdata --natural-foreign --natural-primary --exclude > my_fixture.json
python manage.py loaddata my_fixture.json

Alternatively, one can also solve the root cause: make sure the content types match in the source and destination databases. I faced the same error moving data around between databases where db1 still had content types from apps which had been removed in mean time. Importing these in db2 where the apps were never present results in this error message.

In this case, edit -at database level- the django_content_type table in db1 and remove the content types which are not in use anymore in the django application.
Then migrate or copy the data to db2 again.

If the content types are referenced in other tables, you might need to delete them there first, or use a DROP CASCADE command (risky!).

WARNING: Editing at database level is a risky business so be sure to take a backup before engaging, and don’t do this on production databases.

Depending on the database type, you’ll need a different tool to make the edit.

mysql -> [MySQLWorkBench][1]
postgres -> [pgAdmin][2] 
SQLite -> [SQLite Browser][3]

Have you recently changed to use postgres from mysql?

When querying the contenttypes with something like:

entry_content_type = ContentType.objects.get(
    app_label="entries", model="Entry"
)

This fails because in postgres; app_label and model are all lower case fields. So make use of the __iexact field lookup which will ignore case.

entry_content_type = ContentType.objects.get(
    app_label__iexact="entries", model__iexact="Entry"
)

A lot of the points made in the answers above helped point me to the correct solution for my situation as well.

The problem showed for me while rebuilding Elasticsearch indexes.

Ultimately problem was a FK reference to a non-existant record. How that got there in the first place is still a mystery but creating the record referred to by the foreign key got the process running again.