alembic修订版-多头（应有分支）

Question

我有一个应用程序，今天我想为它创建一个新的迁移。当我跑的时候

$ 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

什么也不给

我是阿伦比奇的新手。有两个开发人员正在开发这个应用程序，我们有两个git分支-master&development（我不确定这是否与它有关）。

有什么线索吗？

Answer 1

也许最传统的（和健壮的）解决方案是使用alembic merge heads。以同样的方式，当您在Git中有两个分支时，可以通过合并提交将它们重新组合在一起；在Alembic中，当您有两个分支时，可以通过合并修订将它们重新组合在一起。

例如，假设我们有一个添加表a的修订版1a6b1a4a0574和一个添加表B的修订版2e49118db057

$ 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

如果您的某个修订可能已经在某个地方运行（包括在您的一个同事的开发机器上），那么您可能希望使用alembic merge，而不是像这里的其他答案所建议的那样，修改其中一个修订的down_revision。修改向下修订的危险在于，它可能导致修订永远无法应用。例如，假设您的同事Bob已经用2e49118db057版本拉下了您的分支，并运行alembic upgrade head，创建了表B，然后您决定修改2e49118db057的down_revision，以指向1A6B1A4 a0574，这是Bob从未见过或运行过的。鲍勃放下你的零钱，跑alembic upgrade head，然后。。。什么也没发生，因为就Alembic而言，他已经在head了，不需要运行1a6b1a4a0574。因此，Bob最终永远得不到表A，也可能永远不知道为什么他的数据库处于崩溃状态。

不要破坏Bob的数据库-改为进行合并修订。

Answer 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

你能看到的是两个不同的分支。一个从49501407aec9开始，第二个从280061454d2a开始

$ python manage.py db revision

它创建了一个新的迁移文件。

Answer 3

当两个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

您可以看到，第五次修订中的一次是在本地进行的，它的下游修订是2f4682466279，但是无论谁进行了第五次修订，都得到了相同的下游修订。

进入第五个修订版文件之一并更新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

在本例中，我更新了migrationf34e92e9dc54以拥有down_revision='f673ac37b34a'。