Djangoのマイグレーションが中止されました

Question

私はDjangoには自信がありますが、ほとんどの場合、最近までに生成されたマイグレーションに依存していました。私は小さなカスタムマイグレーションを書いていました。そして、CIがタイムアウトについて不満を持ち始めた直後に、デプロイメント中にDjangoからの移行に関係していました。

まず、私はこの問題を解決できましたが、修復したことがあれば何をしたのか分かりません。この問題は、特定の移行のために入力したカスタムコードに関連しているようです。ここで私は知っているものだ：

• 最初は、すべてが大丈夫だったが、移行は、私のカスタムコードを追加した後に（比較的）を実行する本当に長い時間を取り始めました。時間は約10秒です。
• 時々動作します。すなわち、コマンドラインから10回マイグレーションを実行すると、時々動作し、失敗することがあります。
  まず

  [web@dev myapp]$ ./manage.py migrate 
  Operations to perform: 
      Apply all migrations: myapp1, myapp2, myapp3, myapp4 
  Running migrations: 
  Killed 
  

  • 私は前に2つのフィールド間のコピーデータPythonの機能を実行するためにRunPythonを使用していますので、それが思った次のように出力が（アプリ名が出て編集した）である

  フィールドの1つを削除します。このドキュメントでは、PostgreSQLの使用を推奨していませんが、これを行うにはより良い方法がありますか？

• ここでのビジネスシナリオでは、一連のオプション（CharField options）に切り替えるために必要なブール値フィールドがあることです。ブール値がtrueであるかどうかをチェックし、文字フィールドに正しい値を設定します。私はこれを2回しました。初めての作業は結局終わりましたが、まだ別のデータベースでテストしていません。

これは、移行（アプリ名が出て編集した）である：

from __future__ import unicode_literals 

from django.db import migrations 

def fix_consulting(apps, schema_editor): 
    my_model = apps.get_model("myapp", "MyModel") 
    for m in my_model._default_manager.all(): 
     if m.consulting: 
      m.detail = "CONSLT" 
      m.save() 


class Migration(migrations.Migration): 

    dependencies = [ 
     ('myapp', '0024_auto_20160117_1113'), 
    ] 

    operations = [ 
     migrations.RunPython(fix_consulting,atomic=False), 
    ] 

私の考え：

• たぶん私はここに書いているコードは実行に時間がかかりすぎますか？データベースには100個未満のモデルがあるので、なぜfix_consulting関数が長らくかかるのか分かりません。

• fix_consultingの先頭にprintステートメントを追加すると、それらは時々のみ実行され、他の時間は強制終了されます。現状では、私はそれを6-8回を走ったのだが、毎回殺されているが、異なる点で

その他の情報： - Djangoの1.9 を使用して - PostgreSQLの9.4.4 を使用する - エラー主にCentOS上で発生しますが、OSXでも発生します

Answer 1

この問題は、allを使用する際にキャッシュする必要があるデータの量がオブジェクトのすべてのインスタンスを返すために発生したと考えられます。オブジェクトを返す前にレベルを変更する必要があります。フィールドの値を変更する必要があるだけで、データベースレベルでも変更できます。これにより、コードが次のように変更されます。

def fix_consulting(apps, schema_editor): 
    my_model = apps.get_model("myapp", "MyModel") 
    my_model._default_manager.filter(consulting=True).update(detail="CONSLT") 

これは、問題を解決したと思われるデータベースのメモリ管理責任を表します。今後

、私はあなたのマシンがちょうどできないこと、その可能性