3

プロジェクトの一部のデッド コードを削除している最中であり、プロジェクトの開始以来使用してきたサード パーティ アプリへの依存関係を削除する機会があります。私たちのモデルの 1 つに、サードパーティ製アプリのモデルへの ForeignKey があり、プロジェクトの新しいインスタンスに移行を適用しようとすると問題が発生します。

モデル例:

from django.db import models
from thirdparty.models import ThirdPartyModel

class MyModel(models.Model):
    fk = models.ForeignKey(ThirdPartyModel)

South によって削除MyModel.fkが検出され、移行が正常に作成されます。移行の適用とロールバックも機能します。これで、変更を削除thirdpartyしINSTALLED_APPSてコミットできます (新しい移行とsettings.py)。

別のマシンでリポジトリを複製すると、問題が発生します。 ./manage.py syncdb期待どおりに実行され、South によって管理されていないすべてのテーブルが作成されますが、./manage.py migrate myapp(の初期バージョン) のテーブルを作成するときに失敗します。MyModelthirdparty_thirdpartymodelthirdpartyINSTALLED_APPS

外部依存関係の削除を処理する標準的な方法はありますか? これは、移行をリセットする適切な時期ですか?

4

1 に答える 1

0

これは古い質問ですが、今でも有効であり、South から独立しており、Django Migrations の問題でもあります。

存在しないアプリ (から削除) に依存する移行を偽造できるように、移行ファイルが分離されていることに注意する必要がありますINSTALLED_APPS。そうすれば、それらの移行を偽装して新しいインストールを作成し、実際にそれらの移行を既存のインストールで実行することになります。

もちろん、最初からやり直す可能性がある場合 (完全な再起動など)、データベースを消去し、既存の移行ファイルをすべて削除して、完全に新しい移行を作成するだけです。他のすべての開発者も、データベースを削除する必要があります。

既存の本番データがあり、それでも最初からやり直したい場合、データの転送方法にはさまざまな可能性があります。どの方法が最適かは、データの量、構造の変更量などによって異なります。

  • プレーン SQL (新しい移行を実行した後、古いテーブルから新しいテーブルにデータを転送してテーブルを削除し、外部キーなどを使用して、手動で DB を変更します。)
  • フィクスチャ (古いシステムで Django を介してデータをダンプし、JSON を新しい構造に合わせて変更します)
  • 古いシステムと新しいシステムの 2 つの並列インストールと、Django/Python スクリプトを介した転送 (プレーンな SQL よりも低速ですが、Django モデル ロジックを利用し、検証チェックや変換などをより快適な方法で適用できます)。

もちろん、これを本番環境で行うのではなく、他の場所で行い、単純に結果を適用してください。

于 2016-01-13T08:45:55.933 に答える