MySQL へのロード時に Django フィクスチャの ContentType の競合を解決するにはどうすればよいですか?

Django フィクスチャと ContentType の問題

Django フィクスチャを MySQL データベースにロードしようとすると、コンテンツ タイプの競合が発生する可能性があります。特定のアプリからデータをダンプすると、最初は外部キーの欠落の問題が発生するため、ダンプ コマンドに追加のアプリを含める必要があります。ただし、このアプローチでフィクスチャをロードすると、コンテンツ タイプの主キーの競合により制約違反が発生します。

この状況は、フィクスチャに存在するものとは異なる主キー値を使用してコンテンツ タイプを動的に再作成しようとする Django の試みに起因します。 Django のバグ追跡システムで提案されているように、回避策はコンテンツ タイプ アプリからデータをダンプすることです。

ただし、カスタム モデルのアクセス許可が定義されている場合、推奨される解決策には疑問が生じます。これを解決するには、dumpdata コマンドで --natural を使用することをお勧めします。このオプションでは、外部キーに自然キーを使用するため、耐久性が向上します。

このアプローチを示す例は次のとおりです。

./manage.py dumpdata --natural escola > fixture.json

さらに、dumpdata で使用できる便利な引数が他にもあります。 :

• --indent=4: インデントすることで読みやすさを向上させます。 Output
• -e session: ダンプからセッション データを除外します
• -e admin: 管理アクションの履歴を除外します
• -e contenttypes -e auth.Permission: オブジェクトを除外しますsyncdb 中に自動的に再作成されますが、主キーの配置の問題を防ぐために --natural が必要です

以上がMySQL へのロード時に Django フィクスチャの ContentType の競合を解決するにはどうすればよいですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。