削除されたDjango移行を復旧しました

Question

私のプロダクションサーバーで、私のアプリケーションのいずれかでマイグレーションディレクトリを誤って削除しました。複数の人がアプリケーションを操作するので、アプリケーションを作成するときにローカルでマイグレーションを行わずに、モデルの変更をプッシュし、本番サーバーでマイグレーションを行い、マイグレーションするだけでした。過去に移行の問題をマージしていたため、これを実行しました。これが良い解決策であると考えました。移行フォルダのローカルコピーが存在しないので、永遠に消えてしまう恐れがあります。私の質問はこれです。私はWebfactionのphpPgAdminにアクセスでき、データベースにはdjango_migrationsテーブルがあります。私は、最新バージョンのマイグレーションを見つけて、例えば0009_migration.pyと言うことを考え、将来そのマイナーチェンジファイルを将来変更する場合は、新しいマイグレーションファイル0010_migration.pyの名前を変更するだけです。そうすれば、私は単純にマイグレーションを実行することができます。それは、マイグレーションがまだ実行されていないこと、すなわち0010_migration.pyだけが考慮されます。しかし好奇心の念から、あなたのPostgreSQLデータベースを見て、django_migrationsテーブルのファイルにある移行レコードから、あなたのアプリケーション移行ディレクトリに移行ファイルを作成するコマンドがありますか？

私はこれを依頼する簡単な方法があると思います「はmigrations.pyファイルにエンジニアdjango_migrationsテーブルの行を逆にそこの方法です？」ここで私は、PostgreSQLを持っているdjango_migrationテーブルの行の画像であり、どのようなI異なるコマンドを使ってファイルを見たいと思うでしょう。

ジャンゴ移行

class Migration(migrations.Migration): 

    dependencies = [ 
     ('portfolio', '0001_initial'), 
    ] 

    operations = [ 
     migrations.AddField(
      model_name='project', 
      name='contact_form', 
      field=models.BooleanField(default=False), 
     ), 
    ] 

PostgreSQLのdjango_migrationsテーブル行

Answer 1

1）データベースの移行テーブルからの移行ファイル削除されたことを1つのアプリのためのすべてのentiresを削除します。

2）$ python manage.py makemigrations <app>

これは新しいマイグレーションファイル（initalマイグレーション）を作成します。

3）$ python manage.py migrate <app> --fake

は移行テーブルに最初の移行を書き込みなく（実際には移動しない）他のテーブルに触れていません。

マイグレーションファイルが削除されたアプリに変更が加えられていない限り動作するはずです。

これは、誤ってマイグレーションファイルを削除した場合の問題を解決する可能性があります（自動作成されていて、操作されていないと仮定します）。しかし、私はそれが可能かどうか、またはリファクタリングテーブルをリファクタリングすることが推奨されるかどうかはわかりません。また、マイグレーションファイルの自動作成、自動作成後の任意のマイグレーションファイルの手動操作が必要になるまたは、djangoバックエンドを上書きする必要があります。

編集

コメントで追加の質問への回答：

• 初期$ python manage.py makemigrations <app>が与えられたアプリでのモデルのすべての現在のスキーマを記述する移行ファイルを作成します（$ python manage.py makemigrationsがためのことを行いますすべてのアプリ）。
• 初期$ python manage.py migrate <app>
は、データベースに特定のアプリのすべての移行ファイルを適用し、移行ファイルが適用されたことで、あなたの移行テーブル に書き込みます。最初の移行では、必要な属性とリレーションを持つ必要なデータベーステーブルがすべて作成されます（$ python manage.py migrateはすべてのアプリケーションでそれを行います）。 $ python manage.py makemigrations <app>後
• は違いlates移行ファイル（そう、このアプリでモデルのスキーマの最新記述）と、このアプリでモデルの現在スキーマ間を記述する移行ファイルを作成します。
• データベースの移行テーブルには、の移行ファイルののアプリケーションがデータベースに適用されたという情報が格納されています。
• $ python manage.py migrate <app>に従うと、その移行テーブルを使用して、どの移行ファイルが既にデータベースに適用されているかを確認します。適用されていない場所にある移行ファイルがある場合は、適用されて移行テーブルに書き込まれます。

アプリの移行ファイルを削除するのであれば、あなたはちょうどそのアプリのモデルのスキーマの説明と歴史を削除します。移行テーブルのエントリにも同じです。に関する情報を削除するだけです。移行ファイルはデータベースに適用されます。また

• $ manage.py migrate <app> --fake移行ファイルがデータベースに適用されなければならないし、またあなたの移行テーブルにすべての移行ファイル・ツー・適用することを書き込みチェック。しかし、このコマンドは、をデータベースに適用しません。

だから私は提案し、実際のソリューションが何をするか、次のされています。移行ファイルを1つの特定のアプリ

については、データベースに適用されたかについて

1. 削除情報は、その1の1つの新しい移行ファイルを作成します。 app
2. 移行ファイルを移行テーブルに書き込みますが、適用しないでください。 < <これは、マイグレーションファイルが削除されているため、アプリのモデルに変更を加えてはいけない理由です。

移行テーブルの既存のエントリを削除する必要があるのはなぜですか？

質問に記載されている画像のとおり、移行のエントリには、適用された移行ファイルの名前がのが格納されています。これらのエントリを削除しないと、manage.py migrateには同じ名前（または番号 - 100％認識していない）の移行ファイルが既に適用されているものと想定されます。そのため、これらは移行時にスキップされます。