blocks|key|1560080|text|尝试在创建fixture时跳过contenttype：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1560081|./manage.py+dumpdata+--exclude+contenttypes+>+fixture.json|code-block|syntax|javascript|1560082|它在单元测试的类似情况下对我很有效，你对内容类型的见解真的很有帮助！|1560083|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|L|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|M|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

Try skipping contenttypes when creating fixture:

<pre><code>./manage.py dumpdata --exclude contenttypes &gt; fixture.json
</code></pre>

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

blocks|key|1344554|text|我已经在我的测试用例中解决了这个问题，方法是在加载转储文件之前从单元测试中重置contenttypes应用程序。卡尔已经建议使用manage.py命令，而我只使用call_command方法做同样的事情：|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1344555|>>>+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)|code-block|syntax|javascript|1344556|我的full_test_data.json+fixture包含与其余测试数据相对应的内容类型应用程序转储。通过在加载前重置应用程序，它可以防止重复的密钥IntegrityError。|1344557|entityMap^0|1S|9|29|C|0|0|2|J|24|E|0^^$0|@$1|2|3|4|5|6|7|O|8|@$9|P|A|Q|B|C]|$9|R|A|S|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|T|8|@]|D|@]|E|$I|J]]|$1|K|3|L|5|6|7|U|8|@$9|V|A|W|B|C]|$9|X|A|Y|B|C]]|D|@]|E|$]]|$1|M|3|-4|5|6|7|Z|8|@]|D|@]|E|$]]]|N|$]]

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 <code>manage.py</code> command and I do the same thing only using the <code>call_command</code> method:

<pre><code>&gt;&gt;&gt; from django.core import management
&gt;&gt;&gt; management.call_command("flush", verbosity=0, interactive=False)
&gt;&gt;&gt; management.call_command("reset", "contenttypes", verbosity=0, interactive=False)
&gt;&gt;&gt; management.call_command("loaddata", "full_test_data.json", verbosity=0)
</code></pre>

My <code>full_test_data.json</code> 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 <code>IntegrityError</code>.

blocks|key|1344638|text|这真的真的很烦人。每一次我都会被它咬到。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1344639|我尝试使用--排除内容类型和--natural来转储数据，我总是遇到问题..|1344640|对我来说，最有效的方法是在同步数据库之后执行一次truncate+table+django_content_type;，然后加载数据。|offset|length|style|CODE|1344641|当然，对于initial_data.json的自动加载来说，你是在跌倒。|1344642|entityMap^0|0|0|O|Z|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|P|8|@$F|Q|G|R|H|I]]|9|@]|A|$]]|$1|J|3|K|5|6|7|S|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|M|$]]

It's really, really annoying .. I get bitten by this every single time.

I tried to dumpdata with --exclude contenttypes and --natural, I always get problems..

What works best for me is simply doing a <code>truncate table django_content_type;</code> after the syncdb and THEN load the data.

Of course for initial_data.json autoloading you're fallball.

blocks|key|1344723|text|我以前也遇到过类似的错误。事实证明，我试图在创建必要的表之前加载fixture。所以我就这么做了：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1344724|$+python+manage.py+makemigrations
$+python+manage.py+migrate
$+python+manage.py+loaddata+fixtures/initial_data.json|code-block|syntax|javascript|1344725|它的效果就像一个护身符|1344726|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|L|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|M|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

I had encountered similar error sometimes ago. It turned out that I was trying to load the fixtures before creating the necessary tables. So I did:

<pre><code>$ python manage.py makemigrations
$ python manage.py migrate
$ python manage.py loaddata fixtures/initial_data.json
</code></pre>

And it worked like a charm

blocks|key|1560305|text|我没有使用MySQL，而是将一些数据从实时服务器导入到sqlite中。在执行loaddata之前清除contenttypes应用程序数据做到了这一点：|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1560306|from+django.contrib.contenttypes.models+import+ContentType
ContentType.objects.all().delete()
quit()|code-block|syntax|javascript|1560307|然后|1560308|python+manage.py+loaddata+data.json|1560309|entityMap^0|12|8|1E|C|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@$9|R|A|S|B|C]|$9|T|A|U|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|V|8|@]|D|@]|E|$I|J]]|$1|K|3|L|5|6|7|W|8|@]|D|@]|E|$]]|$1|M|3|N|5|H|7|X|8|@]|D|@]|E|$I|J]]|$1|O|3|-4|5|6|7|Y|8|@]|D|@]|E|$]]]|P|$]]

I was not using MySQL but instead importing some data from a live server into sqlite. Clearing the <code>contenttypes</code> app data before performing <code>loaddata</code> did the trick:

<pre><code>from django.contrib.contenttypes.models import ContentType
ContentType.objects.all().delete()
quit()
</code></pre>

And then

<pre><code>python manage.py loaddata data.json
</code></pre>

blocks|key|1560380|text|这里的答案都是旧的..。截至2017年，最好的答案是：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1560381|manage.py+dumpdata+--natural-foreign+--natural-primary+-e+contenttypes+-e+auth.Permission+--indent+4|code-block|syntax|javascript|1560382|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

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

<pre><code>manage.py dumpdata --natural-foreign --natural-primary -e contenttypes -e auth.Permission --indent 4
</code></pre>

blocks|key|1560435|text|./manage.py+dumpdata+app.Model+--natural-foreign|type|code-block|depth|inlineStyleRanges|entityRanges|data|syntax|javascript|1560436|将会改变|unstyled|1560437|++"content_type":+123|1560438|至|1560439|++"content_type":+[
++++"app_label",
++++"model"
++],|1560440|而fixture现在适用于TestCase|offset|length|style|CODE|1560441|entityMap^0|0|0|0|0|0|D|8|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$B|C]]|$1|D|3|E|5|F|7|V|8|@]|9|@]|A|$]]|$1|G|3|H|5|6|7|W|8|@]|9|@]|A|$B|C]]|$1|I|3|J|5|F|7|X|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|Y|8|@]|9|@]|A|$B|C]]|$1|M|3|N|5|F|7|Z|8|@$O|10|P|11|Q|R]]|9|@]|A|$]]|$1|S|3|-4|5|F|7|12|8|@]|9|@]|A|$]]]|T|$]]

<pre><code>./manage.py dumpdata app.Model --natural-foreign
</code></pre>

will change 

<pre><code> "content_type": 123
</code></pre>

to

<pre><code> "content_type": [
 "app_label",
 "model"
 ],
</code></pre>

And fixture works for <code>TestCase</code> now

blocks|key|1344977|text|在我的例子中，我转储了来自auth+(./manage.py+dumpddata+auth+>+fixtures/auth.json)的数据，以便使用该装置进行测试。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1344978|开发还在继续，我删除了我在models.py中定义的大多数模型，这就是我开始看到这个恼人的问题的时候。|1344979|我的解决方案是再次重新生成auth.json装置。这个版本在auth.permission中删除了很多与我的旧模型相关的条目。|1344980|entityMap^0|D|4|J|1B|0|D|9|0|U|F|0^^$0|@$1|2|3|4|5|6|7|L|8|@$9|M|A|N|B|C]|$9|O|A|P|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|Q|8|@$9|R|A|S|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|T|8|@$9|U|A|V|B|C]]|D|@]|E|$]]|$1|J|3|-4|5|6|7|W|8|@]|D|@]|E|$]]]|K|$]]

In my case I had dumped the data from <code>auth</code> (<code>./manage.py dumpddata auth &gt; fixtures/auth.json</code>) to use the fixture for testing purposes.

The development continued and I removed most of the models I had defined in <code>models.py</code> and this is when I started to see this annoying problem.

My solution was regenerating the auth.json fixture again. This one had removed lots of entries in <code>auth.permission</code> related to the old models I had.

blocks|key|1560547|text|我尝试了上面的每一种方法，没有一种对我有效。我必须排除完整的身份验证模型，并且工作得很好。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1560548|python+manage.py+dumpdata+--natural-primary+--exclude=contenttypes+--exclude=auth+--exclude=admin.logentry+--exclude=sessions.session+--indent+4+>+live.json|code-block|syntax|javascript|1560549|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

I tried every method from above, Nothing worked for me. I have to exclude the complete auth model and works fine.
<pre><code>python manage.py dumpdata --natural-primary --exclude=contenttypes --exclude=auth --exclude=admin.logentry --exclude=sessions.session --indent 4 &gt; live.json
</code></pre>

blocks|key|1560583|text|我已经通过在我的测试中添加setUp和tearDown修复了这个问题|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1560584|from+django.core+import+management|code-block|syntax|javascript|1560585|=====|1560586|def+setUp(self):
++++management.call_command("loaddata",+"all-data.yaml",+verbosity=0)
++++super(login_page_test,+self).setUp()

def+tearDown(self):
++++management.call_command("flush",+verbosity=0,+interactive=False)
++++super(login_page_test,+self).setUp()|1560587|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|N|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|O|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|P|8|@]|9|@]|A|$E|F]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

I've fixed this by adding in my tests setUp and tearDown
<pre><code>from django.core import management
</code></pre>
=====
<pre><code>def setUp(self):
 management.call_command(&quot;loaddata&quot;, &quot;all-data.yaml&quot;, verbosity=0)
 super(login_page_test, self).setUp()

def tearDown(self):
 management.call_command(&quot;flush&quot;, verbosity=0, interactive=False)
 super(login_page_test, self).setUp()
</code></pre>

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:

<pre><code>./manage.py dumpdata escola &gt; fixture.json
</code></pre>

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:

<pre><code>./manage.py dumpdata contenttypes auth escola &gt; fixture.json
</code></pre>

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

<pre><code>IntegrityError: (1062, "Duplicate entry 'escola-t23aluno' for key 2")
</code></pre>

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: <a href="http://code.djangoproject.com/ticket/7052" rel="noreferrer">http://code.djangoproject.com/ticket/7052</a>

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: <a href="http://docs.djangoproject.com/en/dev/ref/models/options/#permissions" rel="noreferrer">http://docs.djangoproject.com/en/dev/ref/models/options/#permissions</a>

Problems with contenttypes when loading a fixture in Django

身份验证

单元测试

SQL数据库

数据库

服务器

Django

MySQL

由于内容类型冲突，我在将Django fixture加载到我的MySQL数据库时遇到了问题。首先，我尝试只从我的应用程序中转储数据，如下所示：./manage.py dumpdata escola > fixture.json但我总是遇到缺少外键的问题，因为我的应用程序"escola“使用了其他应用程序中的表。我一直在...

问在Django中加载fixture时的内容类型问题
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在Django中加载fixture时的内容类型问题EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在Django中加载fixture时的内容类型问题
EN