我最近尝试将一些灯具加载到我的数据库中。当我运行服务器并加载各种页面时，我收到错误：
Caught DoesNotExist while rendering: ContentType matching query does not exist.
我已经尝试过运行syncdb，并单独重置每个应用，但没有任何运气。如何使此错误消失？
答案 0 :(得分：12)
如果您查看夹具内部，每个夹具都有三个根域：PK，fields（该表中PK'th条目的一组字段）和{{1} }，包含appname.modelname，ORM从中派生表信息。
这是appname.modelname，Django通过ContentType引擎查找，以确定将数据放入哪个表。
您的朋友至少给了您一个夹具，其中model字段的内容与您数据库中的任何实际型号都不匹配。这可能是拼写错误，误解，模型或应用程序名称的更改，或任何数量的错误。但是夹具与项目中的任何模型都不对应，并且夹具导入器告诉您，通过说它不能将模型的指定名称与项目ContentType表中的任何名称相匹配。
修复可能很简单，只需要确定表格应该作为ContentType的内容，然后打开夹具并在model行上进行大规模搜索和替换。
编辑：
这是一个漫长的（长期！）逾期编辑。如果你要在model:包含通用数据或在其他地方对通用表的引用，那么必须（我真的不能强调你必须多少）学习dumpdata标志。它不是按编号保存contentType信息，而是按名称保存，使数据库重新加载更容易，更容易出错。
答案 1 :(得分：1)
您可以手动检查数据库中的每个ContentType表，或者：
或者您可以使用其中一个Django迁移工具：
可访问的django-evolution
或更复杂的south
答案 2 :(得分：0)
我找到了导致此错误的不同原因，我想添加以防万一这有助于其他任何人。导致此问题的原因是我创建了一个具有特定权限的组，然后卸载了该组中引用的应用程序。
具体来说，我曾在一个点上安装了reversion，并创建了一个名为“Site Editor”的组，该组授予用户创建，编辑和删除修订的权限。后来我卸载了修订版，但是当我运行“dumpdata”命令时，组权限仍然存在：
[
{
"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
}]
当我尝试运行“loaddata”命令时，我一直遇到这个错误：
django.core.serializers.base.DeserializationError:
Problem installing fixture '/Users/me/Documents/Sites/project/path/fixtures/configuration.json':
ContentType matching query does not exist.
我的解决方案是简单地删除任何对revert的引用和fixture本身的版本，如下所示：
[
{
"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
}]
然后我能够毫无问题地导入灯具。
答案 3 :(得分：0)
来自django 1.7，dumpdata选项已更改： 见http://polarhome.com:753/doc/python-django-doc/html/topics/serialization.html
所以你可以使用：
python manage.py dumpdata --natural-foreign --natural-primary --exclude > my_fixture.json
python manage.py loaddata my_fixture.json
或者，也可以解决根本原因：确保源和目标数据库中的内容类型匹配。我在数据库之间移动数据时遇到了同样的错误，其中db1仍然具有同时删除的应用程序中的内容类型。在db2中导入这些应用程序从未出现过这些导致此错误消息。
在这种情况下，编辑-at database level- db1中的django_content_type表，并删除django应用程序中不再使用的内容类型。 然后再次将数据迁移或复制到db2。
如果在其他表中引用了内容类型，则可能需要先将其删除，或使用DROP CASCADE命令（冒险！）。
警告：在数据库级别进行编辑是一项有风险的业务，因此请确保在使用之前进行备份，而不要在生产数据库上执行此操作。
根据数据库类型的不同，您需要使用其他工具进行编辑。
mysql -> [MySQLWorkBench][1]
postgres -> [pgAdmin][2]
SQLite -> [SQLite Browser][3]
答案 4 :(得分：0)
在某些情况下，当您的fixture包含对不存在的模型的引用时会导致此错误，原因是它尚未安装或其应用尚未添加到您的INSTALLED_APPS中。不幸的是，Django的错误信息在跟踪时非常无用。
如果您修改Queryset.get中的django/db/models/query.py方法以打印*args和**kwargs已通过，则会收到更有用的错误消息，例如：
DeserializationError: Problem installing fixture ... ContentType matching query does not exist. args=() kwargs={'model': u'somenewmodel', 'app_label': u'somenewapp'}
然后您可以检查是否已安装此型号/应用程序，或从夹具中删除这些记录。
答案 5 :(得分：0)
您最近更改了使用postgres中的mysql吗？
使用类似以下内容查询contenttypes时：
entry_content_type = ContentType.objects.get(
app_label="entries", model="Entry"
)
此操作失败，因为在postgres中； app_label和model均为小写字段。因此，请使用__iexact字段查找，它将忽略大小写。
entry_content_type = ContentType.objects.get(
app_label__iexact="entries", model__iexact="Entry"
)
答案 6 :(得分：0)
经过很多试验，这对我有用。我在组和日志方面遇到很多麻烦。
在sqllite上，启动服务器，转到admin并删除所有组。然后在shell中键入以下内容：
python manage.py dumpdata --natural-foreign --natural-primary -e contenttypes -e auth.Permission -e admin.Logentry> datadump_3.json
在 settings.py
python manage.py loaddata datadump_3.json