私はアプリケーションを持っているので、今日、そのための新しいマイグレーションを作成したいと思いました。私が走るとき
$ alembic revision -m "__name__"
メッセージをもらいました
Only a single head is supported. The script directory has multiple heads (due branching), which must be resolved by manually editing the revision files to form a linear sequence.
Run `alembic branches` to see the divergence(s).
ランニング
alembic branches
何も与えない
私はalembicが初めてです。このアプリで作業している開発者は2人で、gitブランチは2つあります-マスターと開発(これに何か関係があるかどうかはわかりません)。
これについての手がかりはありますか?
私は走った
$ python manage.py db history
そしてその結果、私は得ました
vagrant@precise64:/vagrant$ python manage.py db history
Rev: 29c319804087 (head)
Parent: 313837798149
Path: migrations/versions/29c319804087_.py
empty message
Revision ID: 29c319804087
Revises: 313837798149
Create Date: 2014-03-05 21:26:32.538027
Rev: 313837798149
Parent: 280061454d2a
Path: migrations/versions/313837798149_.py
empty message
Revision ID: 313837798149
Revises: 280061454d2a
Create Date: 2014-01-10 03:19:39.838932
Rev: 280061454d2a
Parent: None
Path: migrations/versions/280061454d2a_.py
empty message
Revision ID: 280061454d2a
Revises: None
Create Date: 2013-12-08 03:04:55.885033
Rev: 2e74f61d3b80 (head)
Parent: 49501407aec9
Path: migrations/versions/2e74f61d3b80_o2_lease.py
o2 lease
Revision ID: 2e74f61d3b80
Revises: 49501407aec9
Create Date: 2014-02-28 10:38:06.187420
Rev: 49501407aec9
Parent: None
Path: migrations/versions/49501407aec9_.py
empty message
Revision ID: 49501407aec9
Revises: None
Create Date: 2014-01-22 11:27:08.002187
ここに表示されているのは、2つの異なるブランチです。 1つは49501407aec9から始まり、2つ目は280061454d2aから始まります。 49501407aec9と次の2e74f61d3b80を/ versionsディレクトリから移動し、実行します
$ python manage.py db revision
そして、それは新しい移行ファイルを作成しました。
この問題は、2つのalembic移行が同じ移行から分岐した場合に発生します。通常、これは複数の人がスキーマを変更しているときに発生します。これを修正するには、マイグレーションの_down_revision
_を最新のものに調整する必要があります。 _alembic history
_を実行すると、次のようになります。
_2f4682466279 -> f34e92e9dc54 (head), Fifth revision (on a separate branch)
2f4682466279 -> f673ac37b34a (head), Fifth revision (local)
2dc9337c3987 -> 2f4682466279, Fourth revision
0fa2aed0866a -> 2dc9337c3987, Third revision
22af4a75cf06 -> 0fa2aed0866a, Second revision
9a8942e953eb -> 22af4a75cf06, First revision
_
5番目のリビジョンの1つがローカルで行われ、そのダウンストリームリビジョンがis _2f4682466279
_であることがわかります。
次のように、5番目のリビジョンファイルの1つに移動し、他の5番目のリビジョンを参照するように_down_revision
_変数を更新します。
_f673ac37b34a -> f34e92e9dc54 (head), Fifth revision (on a separate branch)
2f4682466279 -> f673ac37b34a, Fifth revision (local)
2dc9337c3987 -> 2f4682466279, Fourth revision
0fa2aed0866a -> 2dc9337c3987, Third revision
22af4a75cf06 -> 0fa2aed0866a, Second revision
9a8942e953eb -> 22af4a75cf06, First revision
_
この場合、_f34e92e9dc54
_に移行するように_down_revision='f673ac37b34a'
_を更新しました。
おそらく最も一般的な(そして堅牢な)ソリューションはalembic merge heads
を使用することです。 Gitに2つのブランチがある場合と同じように、マージコミットでブランチを戻すことができます。Alembicでは、2つのブランチがある場合、マージリビジョンでブランチを戻すことができます。
たとえば、テーブルAを追加するリビジョン1a6b1a4a0574と、テーブルBを追加するリビジョン2e49118db057があるとします。これらのリビジョン(両方とも(head)
とマークされています)をalembic history
で確認できます。
$ alembic history
<base> -> 2e49118db057 (head), Add table B
<base> -> 1a6b1a4a0574 (head), Add table A
次に、alembic merge heads
を実行してそれらをマージできます。
$ alembic merge heads
Generating /Users/markamery/alembictest/alembic/versions/409782f4c459_.py ... done
$ alembic history
2e49118db057, 1a6b1a4a0574 -> 409782f4c459 (head) (mergepoint), empty message
<base> -> 2e49118db057, Add table B
<base> -> 1a6b1a4a0574, Add table A
リビジョンの1つがすでにどこかで実行されている可能性がある場合(同僚の1人の開発マシンを含む)、リビジョンのalembic merge
をいじるのではなく、down_revision
を使用することをお勧めします。 、ここの他の答えが示唆するように。ダウンリビジョンをいじくり回す危険性は、リビジョンが適用されない可能性があることです。たとえば、同僚のボブがリビジョン2e49118db057でブランチをすでにプルダウンしてalembic upgrade head
を実行し、テーブルBを作成したとします。次に、2e49118db057のdown_revision
を変更して、ボブが持っている1a6b1a4a0574を指すようにします。以前に見たことも実行したこともありません。ボブはあなたの変更を引き下げ、alembic upgrade head
を実行しますが、何も起こりません。なぜなら、Alembicは彼がすでにhead
にいて、1a6b1a4a0574を実行する必要がないためです。そのため、ボブはテーブルAを取得できず、データベースが壊れた状態である理由を理解できません。
ボブのデータベースを壊さないでください-代わりにマージリビジョンを作成してください。