web-dev-qa-db-fra.com

révision d'alambic - erreur de plusieurs têtes (branchement dû)

J'ai une application et je voulais créer une nouvelle migration pour elle aujourd'hui. Quand je cours

$ alembic revision -m "__name__"

J'ai un message

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

Fonctionnement

alembic branches

ne donne rien

Je suis nouveau sur alambic. Il y a 2 développeurs qui travaillent sur cette application et nous avons 2 branches git - master & develop (je ne sais pas si cela a quelque chose à voir avec ça).

Un indice sur ce que c'est?

pythongitalembic
28
Arek S

J'ai couru

$ python manage.py db history

Et en conséquence, j'ai

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

Ce que vous pouvez voir ici est 2 branches différentes. L'un part de 49501407aec9 et le second de 280061454d2a. J'ai déplacé 49501407aec9 et le 2e74f61d3b80 suivant hors du répertoire/versions, exécutez

$ python manage.py db revision

et il a créé un nouveau fichier de migration.

5
Arek S

Ce problème se produit lorsque deux migrations d'alambic sont dérivées de la même migration. Cela se produit généralement lorsque plusieurs personnes effectuent des modifications de schéma. Pour y remédier, il vous suffit de régler ledown_revision de votre migration pour être celle de la dernière. Fonctionnement alembic history nous montre ceci:

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

Vous pouvez voir que l'une des cinquième révisions a été effectuée localement et sa révision en aval est2f4682466279 mais celui qui a effectué l'autre cinquième révision a également obtenu la même révision en aval.

Accédez à l'un des fichiers de cinquième révision et mettez à jour down_revision variable pour référencer l'autre cinquième révision, comme ceci:

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

Dans ce cas, j'ai mis à jour la migration f34e92e9dc54 avoir down_revision='f673ac37b34a'.

24
muzhikas

La solution peut-être la plus conventionnelle (et la plus robuste) consiste à utiliser alembic merge heads. De la même manière que lorsque vous avez deux branches dans Git, vous pouvez les ramener avec un commit de fusion, dans Alembic lorsque vous avez deux branches, vous pouvez les ramener avec une révision de fusion.

Par exemple, supposons que nous ayons une révision 1a6b1a4a0574 qui ajoute la table A et une révision 2e49118db057 qui ajoute la table B. Nous pouvons voir ces révisions (toutes deux marquées comme (head)) dans alembic history:

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

Ensuite, nous pouvons les fusionner en exécutant 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 l'une de vos révisions a peut-être déjà été exécutée quelque part (y compris sur la machine de développement de l'un de vos collègues), vous souhaiterez probablement utiliser alembic merge au lieu de bricoler avec le down_revision d'une des révisions, comme le suggèrent les autres réponses ici. Le danger de bricoler avec la révision à la baisse est qu'elle peut entraîner une révision jamais appliquée. Par exemple, supposons que votre collègue Bob ait déjà supprimé votre branche avec la révision 2e49118db057 et exécutez alembic upgrade head, créant la table B. Ensuite, vous décidez de modifier le down_revision de 2e49118db057 pour pointer vers 1a6b1a4a0574, que Bob n'a jamais vu ou dirigé auparavant. Bob retire votre changement, exécute alembic upgrade head, et ... rien ne se passe, car en ce qui concerne Alembic, il est déjà au head et n'a pas besoin d'exécuter 1a6b1a4a0574. Et donc Bob finit par ne jamais obtenir la table A et ne comprend probablement jamais pourquoi sa base de données est dans un état cassé.

Ne cassez pas la base de données de Bob - faites plutôt une révision de fusion.

20
Mark Amery