在Django中加载fixture时contenttypes的问题
由于内容types冲突，我无法将Django Fixtures加载到我的MySQL数据库中。 首先，我尝试从我的应用程序倾销数据，如下所示：
./manage.py dumpdata escola > fixture.json 但我一直在错过外键问题，因为我的应用程序“escola”使用来自其他应用程序的表。 我不断添加额外的应用程序，直到我得到这个：
./manage.py dumpdata contenttypes auth escola > fixture.json
现在，当我尝试加载数据作为testing夹具时，问题是以下约束冲突：
IntegrityError: (1062, "Duplicate entry 'escola-t23aluno' for key 2")
看来问题是，Django试图dynamic重新创build与主键值不同的主键值的contenttypes。 这似乎与此处logging的错误相同： http : //code.djangoproject.com/ticket/7052
问题是推荐的解决方法是转储我已经在做的contenttypes应用程序！ 是什么赋予了？ 如果它有什么区别，我有一些自定义模型的权限，这里logging： http : //docs.djangoproject.com/en/dev/ref/models/options/#permissions
manage.py dumpdata --natural将使用更持久的外键表示。 在Django中，他们被称为“天然钥匙”。 例如：
-
Permission.codename用于Permission.id -
User.username用于User.id
阅读更多： “序列化django对象”中的自然键部分
dumpdata其他一些有用的参数：
-
--indent=4使其可读。 -
-e sessions排除会话数据 -
-e admin在pipe理站点上排除pipe理员操作的历史logging -
-e contenttypes -e auth.Permission排除每次在syncdb期间从模式重新创build的对象。 只有与--natural一起使用它，否则你可能会得到非常一致的ID号码。
是的，这真的很刺激。 有一段时间我通过在加载fixture之前对contenttypes应用程序执行“manage.py reset”来解决这个问题（以去除与转储版本不同的自动生成的contenttypes数据）。 这工作，但最终我厌倦了麻烦和废弃灯具完全赞成直接SQL转储（当然，那么你失去了DB便携性）。
更新 – 最好的答案是使用--natural标志dumpdata ，如下面的答案中所述。 当我写这个答案时，这个标志还没有存在。
创build灯具时尝试跳过内容types：
./manage.py dumpdata --exclude contenttypes > fixture.json
它在unit testing类似的情况下为我工作，你对内容types的洞察力真的帮助！
我已经在我的testing案例中解决了这个问题，在加载我的转储文件之前，通过重置unit testing中的contenttypes应用程序。 卡尔build议这已经使用manage.py命令，我只使用call_command方法做同样的事情：
>>> 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)
我的full_test_data.json夹具包含与其余testing数据相对应的contenttypes应用程序转储。 通过在加载之前重置应用程序，它可以防止重复的密钥IntegrityError 。
我没有使用MySQL，而是从活动服务器导入一些数据到sqlite中。 在执行contenttypes数据之前清除contenttypes应用程序数据的技巧：
from django.contrib.contenttypes.models import ContentType ContentType.objects.all().delete() quit()
接着
python manage.py loaddata data.json
这里的答案都是旧的…截至2017年，最好的答案是：
manage.py dumpdata --natural-foreign --natural-primary -e contenttypes -e auth.Permission --indent 4
python manage.py dumpdata --natural-primary --exclude=contenttypes --exclude=auth.Permission --exclude=admin.logentry --exclude=sessions.session --indent 4 > initial_data.json
这对我有用。 在这里，我排除了所有的实际模型。
- 如果您看到除了您创build的模型以外的其他模型，则可以安全地排除这些模型。 这种方法的一个缺点是你松散的日志数据以及authentication数据。
我打算给出另一个可能的答案，我刚才知道了。 也许它会帮助OP，也许它会帮助别人。
我有一个多对多的关系表。 它有一个主键和两个外键给其他表。 我发现如果我在夹具中有两个外键与另一个表中已经存在的不同的 pk的另一个项相同的入口，它将会失败。 M2M关系表对于两个外键具有“唯一的一起”。
因此，如果M2M关系正在破裂，请查看它添加的外键，查看您的数据库，看看这对FK是否已经列在不同的PK下。
这真的很烦人..我每次都被这个咬伤。
我试图用–exclude contenttypes和–natural转储数据，我总是遇到问题..
最适合我的是简单地做一个truncate table django_content_type; 在syncdb和THEN加载数据之后。
当然，对于initial_data.json自动加载，你是fallball。
我以前遇到过类似的错误。 事实certificate，我正在试图在创build必要的表之前加载灯具。 所以我做了：
$ python manage.py makemigrations $ python manage.py migrate $ python manage.py loaddata fixtures/initial_data.json
它的function就像一个魅力
