python - Revisión de alambique-error de múltiples cabezas(debido a la bifurcación)

git alembic

Question

Tengo una aplicación y quería crear una nueva migración para ella hoy. Cuando corro

$ alembic revision -m "__name__"

Recibí un mensaje

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).

Corriendo

alembic branches

no da nada

Soy nuevo en alambique. Hay 2 desarrolladores trabajando en esta aplicación y tenemos 2 sucursales de git: masterización y desarrollo (no estoy seguro si esto tiene algo que ver con esto).

¿Alguna pista sobre de qué se trata?

Answer 1

Este problema ocurre cuando dos migraciones de alambique se ramifican desde la misma migración. Por lo general, esto sucede cuando varias personas están haciendo cambios en el esquema. Para solucionarlo, solo tiene que ajustar el down_revision de su migración para que sea el último. La alembic history nos muestra esto:

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

Puede ver que una de las quintas revisiones se realizó localmente y su revisión descendente es 2f4682466279 pero quien haya realizado la otra quinta revisión también recibió la misma revisión descendente.

Vaya a uno de los archivos de la Quinta revisión y actualice la variable down_revision para hacer referencia a la otra quinta revisión, como esto:

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

En este caso, actualicé la migración f34e92e9dc54 para tener down_revision=''f673ac37b34a'' .

Answer 2

He corrido

$ python manage.py db history

Y como resultado tengo

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

Lo que puedes ver aquí es de 2 ramas diferentes. Uno comienza desde 49501407aec9 y el segundo desde 280061454d2a. Moví 49501407aec9 y el siguiente 2e74f61d3b80 fuera del directorio / versiones, ejecute

$ python manage.py db revision

y creó un nuevo archivo de migración.

Answer 3

Quizás la solución más convencional (y robusta) es utilizar alembic merge heads . De la misma manera que cuando tiene dos sucursales en Git, puede volver a unirlas con un compromiso de fusión, en Alembic, cuando tiene dos sucursales, puede volver a unirlas con una revisión de fusión.

Por ejemplo, supongamos que tenemos una revisión 1a6b1a4a0574 que agrega la tabla A, y una revisión 2e49118db057 que agrega la tabla B. Podemos ver estas revisiones (ambas marcadas como (head) ) en la alembic history :

$ alembic history
<base> -> 2e49118db057 (head), Add table B
<base> -> 1a6b1a4a0574 (head), Add table A

Luego podemos fusionarlos ejecutando 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

Si una de sus revisiones ya se ha ejecutado en alguna parte (incluso en la máquina de desarrollo de uno de sus compañeros de trabajo), entonces probablemente desee utilizar la alembic merge lugar de jugar con la down_revision de una de las revisiones, como sugieren las otras respuestas aquí. . El peligro de retoques con la revisión descendente es que puede dar lugar a una revisión que nunca se aplica. Por ejemplo, supongamos que su colega Bob ya ha bajado su rama con la revisión 2e49118db057 y ha ejecutado un alembic upgrade head , creando la tabla B. Entonces, decide modificar el down_revision de 2e49118db057 para apuntar a 1a6b1a4a0574, que Bob nunca ha visto ni corrido antes. Bob baja el cambio, ejecuta el alembic upgrade head y ... no pasa nada, porque en lo que respecta a Alambique, ya está a la head y no necesita ejecutar 1a6b1a4a0574. Y así, Bob termina nunca obteniendo la tabla A y probablemente nunca se da cuenta de por qué su base de datos está en un estado roto.

No rompas la base de datos de Bob, haz una revisión de fusión en su lugar.