2013-07-17 16 views
8

私はDjango 1.5プロジェクトでアプリケーション(MyAppと呼ぶ)を持っています。 MyAppは、カスタムユーザーモデル(MyUser)を定義します。このプロジェクトは、MyUserを参照する別のアプリ(AnotherApp)を使用します。 MyAppはAnotherAppのフィールドを参照します。Django南循環依存

私の開発ノートパソコンですべてうまくいきました。私は自分のプロジェクトをサーバーに配備しようとしています。マイグレーション・ステップに来ると、AnotherAppへの依存によりMyAppが失敗し、AnotherAppがMyAppへの依存を失敗します。どちらも最初の移行で失敗しています(0001)

Running migrations for myapp: 
- Migrating forwards to 0017_auto__blah_blah. 
> myapp:0001_initial 
FATAL ERROR - The following SQL query failed: ALTER TABLE "myapp_mymodel_othermodel" ADD CONSTRAINT "othermodel_id_refs_id_ae052c6d" FOREIGN KEY ("othermodel_id") REFERENCES "anotherapp_othermodel" ("id") DEFERRABLE INITIALLY DEFERRED; 
The error was: relation "anotherapp_othermodel" does not exist 

Error in migration: myapp:0001_initial 
DatabaseError: relation "anotherapp_othermodel" does not exist 


Running migrations for anotherapp: 
- Migrating forwards to 0008_blah_blah. 
> anotherapp:0001_initial 
FATAL ERROR - The following SQL query failed: ALTER TABLE "anotherapp_othermodel" ADD CONSTRAINT "creator_id_refs_id_cff6fecf" FOREIGN KEY ("creator_id") REFERENCES "myuser" ("id") DEFERRABLE INITIALLY DEFERRED; 
The error was: relation "myuser" does not exist 

Error in migration: anotherapp:0001_initial 
DatabaseError: relation "myuser" does not exist 

すべてのアイデア?

+0

この問題(http://south.aeracode.org/ticket/390)のチケットがあります。このチケットには、そのトピックに関する議論があります。 –

答えて

11

ここには実際の循環依存があるようです。しかし、それをかなり簡単に破ることができます:MyAppのm2mテーブルの作成を別の移行に移動します。これを行う最も簡単な方法は、おそらく、0001_initial.pyを新しい名前にコピーし、オリジナルのm2mテーブル(前方と後方)のブロックを削除し、コピー内の他のものをすべて削除することです。

コピーの名前は、0001_initialと0002_whateverの間の順序になるようにする必要があります(例:0001_initial2.py)。 ( "AnotherApp"、 "0001_initial")に依存する必要があります(これは、 "MyApp"、 "0001_initial")に依存する必要があります。

+1

パーフェクト!私は、MyAppの最初の移行でneeds_byを使用し、次にMyAppの2回目の移行についてdepends_onを使用して終了しました。これにより、AnotherApp(別の場所で開発されている)を変更することなく、依存関係を設定することができました。 – askvictor