[解決済み] Django migrate の --fake と --fake-initial について説明します。

質問

私は2年ほど前から Django を使っていますが、いつも使うのをためらっていた機能があります。 マイグレーションの偽造 .

かなりあちこち探しましたが、最も多くの情報を得ることができるのは ドキュメント に書かれていることです。

-フェイク

Django に migrations を適用済みか未適用かをマークするように指示します。 しかし、実際に SQL を実行してデータベースのスキーマを変更することはありません。 データベーススキーマを変更する SQL を実際に実行することなく。

これは、上級ユーザが手動で変更を適用する場合に、現在の移行状態を直接操作するためのものです。 手動で変更を適用している場合、現在の移行状態を直接操作するためのものです。 fake を使用すると、移行状態のテーブルを手動で回復する必要がある状態にする危険性があることに注意してください。 テーブルを、移行を正しく実行するために手動で回復する必要がある状態にする危険があることに注意してください。 を使うと、移行を正しく実行するために手動で回復する必要がある状態に移行状態テーブルを置くリスクがあることに注意してください。

-fake-initial

Django がアプリの初期マイグレーションをスキップできるようにします。 テーブルが既に存在している場合、アプリの最初の移行をスキップすることができます。 操作で作成された全てのモデルの名前を持つデータベーステーブルが既に存在する場合、アプリの初期マイグレーションをスキップできるようにします。このオプションは を使う前のデータベースに対して初めて migrations を実行するときに使います。 に対して初めてマイグレーションを実行するときに使用するためのオプションです。しかし、このオプションは データベーススキーマが一致するかどうか、テーブル名が一致するかどうかまではチェックしません。 既存のスキーマが最初の移行で記録されたものと一致すると確信がある場合にのみ使用するのが安全です。 が最初の移行で記録されたものと一致すると確信がある場合にのみ使用してください。

一般的なアイデアと、この機能を使用したい理由は理解できます。しかし、以下の部分が理解できません。 上級ユーザーのみを対象としています。

どなたか、舞台裏で何が起こっているのか、なぜ手動での復旧が必要なのかを説明していただけませんか。

注意

私は、移行を偽造するときに実行される正確な生の SQL クエリを探しているわけではありません。私は、シーンの背後で起こっていることの一般的なアイデアと、なぜマイグレーションを偽装するのかの例を探しているだけです。 を実行した結果 makemigrations が正しく動作しない状態になる理由の例を探しています。

どのように解決するのですか？

ソースコード(git)において、似たようなモデルを持つ2つのブランチを結合したり、ブランチ間を切り替えたりする必要がある場合、マージの競合に似たデータベースの問題に関連します。誰も意図的にそれを好きではありません。

先週、バグを見つけたり、フィールドやテーブルによってアプリケーションを拡張したりするために、アプリケーションを修正し始めたと想像してください。なぜなら、まだデータベースにあるフィールドを追加する移行があり、その移行の他の部分のみを適用することができるからです。を実行して、移行の SQL コンテンツを見ます。

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

は先週変更した内容と比較し、まだ適用されていて繰り返せないコマンドは削除するかコメントアウトしてください。残りのSQLをすべて手動で実行します。その移行を自動的に適用されるようにマークします。

./manage migrate --fake some_app 0007_new_migration

もし何かを壊してしまったら、おそらく誰も助けてはくれません。なぜなら、移行システムはデータベースの現在の状態をより多く知ることができないからです。したがって、バックアップを取り、メモを書き、サンドボックスを使用し、正確に作業してください。

EDITです。 移行テーブル django_migrations はすべてのアプリで適用されたマイグレーションのシンプルなリストです。このテーブルの行は常にデータベース構造と同期した状態であるべきです。マイグレーションは通常の migrate . (または古い状態への逆移行によって適用されなくなります。もちろん、通常は何らかのデータ損失があります) 偽の移行は 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

マイグレーション（ファイル）とは、インクリメンタルな変化を記述したものであり、かつ models.py を実行するときに比較される、最後のマイグレーションからの差分を評価するための情報です。 makemigrations . これは、いくつかのテーブルが最初は非管理型で、後に管理型になる可能性がある場合にも十分である。(したがって、非管理テーブルも記録されます）。

EDITです。 例：どのように sqlmigrate と --fake を使用することができます。 マイグレーションで壊れたデータベースを修正する (削除されたテーブルを再作成する)ために使用されます。

EDITです。 例 もし、あるアプリケーションのテーブルを削除し、再度 migrate (警告と以下の私のコメントをご覧ください)、おそらく、最初のマイグレーションを含むそのアプリケーションのすべてのマイグレーションを最初にリセットしたいと思うでしょう、擬似マイグレーション名 " ゼロ とします。

./manage migrate --fake some_app zero .