117

contenttypes の競合が原因で、Django フィクスチャを MySQL データベースにロードできません。最初に、次のように自分のアプリからのみデータをダンプしてみました:

./manage.py dumpdata escola > fixture.json

しかし、私のアプリ「escola」は他のアプリケーションのテーブルを使用しているため、外部キーが見つからないという問題が発生し続けました。これに到達するまで、アプリを追加し続けました。

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

問題は、データをテスト フィクスチャとしてロードしようとすると、次の制約違反です。

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

問題は、Django がフィクスチャの主キー値と競合する異なる主キー値を持つ contenttypes を動的に再作成しようとしているようです。これは、ここに記載されているバグと同じようです: http://code.djangoproject.com/ticket/7052

問題は、推奨される回避策は、私が既に行っている contenttypes アプリをダンプすることです!? 何を与える？違いがある場合は、ここに記載されているように、いくつかのカスタム モデルのアクセス許可を持っています: http://docs.djangoproject.com/en/dev/ref/models/options/#permissions

4

16 に答える 16

157

manage.py dumpdata --natural外部キーのより永続的な表現を使用します。django では、それらは「自然キー」と呼ばれます。例えば：

  • Permission.codenameに有利に使用されますPermission.id
  • User.usernameに有利に使用されますUser.id

続きを読む：「djangoオブジェクトのシリアル化」の自然キーセクション

のその他の便利な引数dumpdata:

  • --indent=4人間が読めるようにします。
  • -e sessionsセッションデータを除外
  • -e admin管理サイトでの管理アクションの履歴を除外する
  • -e contenttypes -e auth.Permission中に毎回スキーマから自動的に再作成されるオブジェクトを除外しますsyncdb。一緒にのみ使用して--naturalください。そうしないと、ID 番号が正しく整列されない可能性があります。
于 2010-11-02T08:17:01.017 に答える
35

はい、これは本当にイライラします。しばらくの間、フィクスチャをロードする前に contenttypes アプリで「manage.py reset」を実行して回避しました (ダンプされたバージョンとは異なる自動生成された contenttypes データを取り除くため)。それはうまくいきましたが、最終的には面倒なことにうんざりし、固定具を完全に放棄して、単純な SQL ダンプを支持しました (もちろん、そうすると DB の移植性が失われます)。

更新- 最良の答えは、以下の回答に記載されているように、--naturalフラグを使用するdumpdataことです。この回答を書いたとき、そのフラグはまだ存在していませんでした。

于 2009-05-13T00:58:27.540 に答える
32

フィクスチャを作成するときに contenttypes をスキップしてみてください:

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

単体テストでも同様の状況でうまくいきました。コンテンツタイプに関するあなたの洞察は本当に役に立ちました!

于 2010-05-30T03:03:37.773 に答える
10

ダンプ ファイルをロードする前に単体テストから contenttypes アプリをリセットすることで、テスト ケースでこの問題を解決しました。カールはこれをすでに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のフィクスチャには、残りのテスト データに対応する contenttypes アプリ ダンプが含まれています。ロード前にアプリをリセットすることで、重複キーを防ぎますIntegrityError。

于 2010-10-04T13:41:44.497 に答える
3 
./manage.py dumpdata app.Model --natural-foreign

変更されます

  "content_type": 123

に

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

そしてフィクスチャは今のところ機能しTestCaseます

于 2018-01-25T10:27:35.907 に答える
2

それは本当に、本当に迷惑です..私は毎回これに噛まれます.

--exclude contenttypes と --natural を使用してデータをダンプしようとしましたが、常に問題が発生します。

私にとって最も効果的なのはtruncate table django_content_type;、syncdb の後に単純に実行して、データをロードすることです。

もちろん、initial_data.json の自動読み込みの場合は、失敗します。

于 2011-10-14T14:14:50.553 に答える
1

以前にも同様のエラーが発生したことがあります。必要なテーブルを作成する前にフィクスチャをロードしようとしていたことが判明しました。だから私はした：

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

そして、それは魅力のように機能しました

于 2016-07-05T14:28:35.177 に答える
1

私が考え出した別の可能な答えを与えるつもりです。多分それはOPを助けるでしょう、多分それは他の誰かを助けるでしょう.

多対多の関係テーブルがあります。主キーと、他のテーブルへの 2 つの外部キーがあります。2 つの外部キーが別のpkを持つテーブルに既にある別のエントリと同じであるエントリがフィクスチャにある場合、それは失敗することがわかりました。M2M 関係テーブルには、2 つの外部キーの「一意性」があります。

そのため、壊れているのが M2M 関係である場合は、追加されている外部キーを調べ、データベースを調べて、その FK のペアが別の PK の下に既にリストされているかどうかを確認します。

于 2011-10-06T22:42:50.677 に答える