Django migrate --fakeと--fake-initialについて説明しました

Question

私はDjangoを約2年間利用してきましたが、私はいつも賛成していた機能があります。faking migrations。

私はかなりどこでも見てきたと私は得ることができ、ほとんどの情報は、それがあることを述べdocumentationからです：

--fake

を持つものとして移行をマークするためにDjangoに指示しますまたは が適用されていませんが、実際にはSQLを実行せずに データベーススキーマを変更する必要はありません。

これは、高度なユーザーが手動で変更を適用している場合、現在の の移行状態を直接操作するためのものです。 は、--fakeを使用すると、 の移行を正しく実行させるには、手動で復旧する必要がある状態に移行状態 テーブルを入れるリスクがあると警告しました。

--fake-初期

その移行のすべてのたcreateModel の操作によって作成されたすべてのモデルの名前を持つすべてのデータベース 表がすでに存在する場合Djangoはアプリケーションの最初の移行をスキップすることができます。このオプションは、最初に が移行の使用を前提としているデータベースに対して移行を実行するときに使用するために、 を使用することを意図しています。ただし、このオプションでは一致するテーブル名よりも一致するデータベーススキーマのために をチェックしません。 が初期移行に記録されているものと一致すると確信している場合は、 のみ安全に使用できます。

私は一般的なアイデアを得て、なぜこの機能を使いたいのですか？しかし、これは、が上級ユーザーのみを対象としている部分を理解していません。

シーンの背景に何が起こっているのか、なぜ手動で復旧する必要があるのか​​説明できますか。

NOTE

私は、移行を偽造したときに実行される正確な生のSQLクエリを探していませんよ。私はシーンの後ろで起こっていることの一般的なアイデアと、おそらく のマイグレーションを偽って、makemigrationsが正しく動作しない状態になる理由の例を探しています。

Answer 1

先週、アプリケーションの修正を開始したとします。おそらく、バグが見つかったか、フィールドや列で拡張したと考えられます。今日は更新を受け取りました。問題はあります。これは、データベースにまだ存在するフィールドを追加する移行が存在し、その移行の他の部分だけを適用できるためです。あなたは

./manage sqlmigrate some_app 0007_new_migration >customized-some_app-0007_new_migration.sql 

を実行することによって、そのSQLの内容を見ると、先週行われた変更とコンテンツと削除を比較したり、まだ適用されており、繰り返すことができないコマンドをコメントアウトします。残りのSQLはすべて手動で実行してください。

./manage migrate --fake some_app 0007_new_migration 

をあなたは誰もが、おそらくあなたとあなたまたは移行システムでもないが、データベースの現在の状態を知って助けることができない何かを壊した場合：そのような移行を自動的に適用することをマーク。したがって、バックアップ、ノートの書き込み、サンドボックスの使用、正確な作業。

EDIT移行テーブルdjango_migrationsは、すべてのアプリケーションで適用されるマイグレーションの単純なリストです。この表の行は、常にデータベース構造と同期した状態でなければなりません。移行は通常の移行によって適用できます。 （または、通常はデータが失われた古い状態への逆の移行によって適用されなくなります）。偽の移行は変更をdjango_migrationsテーブルにのみ適用します。

me => select * from django_migrations; 
id | app  |   name   |   applied    
----+----------+-------------------------+------------------------------- 
    1 | some_app | 0001_initial   | 2017-10-16 06:11:07.31249+02 
    2 | some_app | 0002_auto_20171016_1905 | 2017-10-17 02:05:48.979295+02 

移行（ファイル）makemigrationsを実行しながら、最後の移行以来、モデルの違いを評価可能にする増分変化や情報の記述です。一部の表が最初に管理されておらず、後で管理される可能性がある場合でも十分です。

EDITsqlmigrate--fakeとは、（削除されたテーブルを再作成する）fix a broken database by migrationsために使用することができる方法の例。