web-dev-qa-db-ja.com

Django migrate --fakeおよび--fake-initialの説明

私は約2年間Djangoのユーザーであり、常に使用することを恐れている機能があります:偽の移行

私はほとんどどこでも見ましたが、私が得ることができるほとんどの情報は documentation からです。

-fake

Djangoに、マイグレーションを適用済みまたは未適用としてマークするように指示しますが、データベーススキーマを変更するために実際にSQLを実行することはありません。

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

-fake-initial

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

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

誰かが舞台裏で何が起こっているのか、なぜ手動で回復する必要があるのか​​を説明できますか。

NOTE

移行を偽装するときに実行される正確な生のSQLクエリを探しているわけではありません。舞台裏で何が起こっているのか、おそらく移行を偽造するとmakemigrationsが正しく機能しない状態になる理由の例だけを探しています。

21
scharette

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

バグを発見したか、フィールドまたはテーブルでアプリを拡張したために、先週、アプリケーションの変更を開始したと想像してください。データベースにまだあるフィールドを追加する移行があり、その移行の他の部分のみを適用できるため、今日、アップデートを受け取って問題が発生しました。次を実行して、移行の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

移行(ファイル)は、増分変更の説明であり、makemigrationsの実行時に比較される、最後の移行以降のmodels.pyの違いを評価できる情報でもあります。一部のテーブルが最初は管理されておらず、後で管理される可能性がある場合にも十分です。 (したがって、管理されていないテーブルも記録されます。)

EDIT:例:--fakesqlmigrateを使用して 移行によって破損したデータベースを修正する (to削除されたテーブルを再作成します)。

20
hynekcer