GeoNature
GeoNature copied to clipboard
PnX-SI
Question Alembic - rebase d'un fichier de migration
J'ai créé un fichier de migration afin de rajouter une table à un moment X.
"""add table gn_synthese.t_reports
Revision ID: 829a376daa52
Revises: 095da7bc6667
Create Date: 2022-03-17 10:57:55.989648
# revision identifiers, used by Alembic.
revision = '829a376daa52'
down_revision = '095da7bc6667'
branch_labels = None
depends_on = None
Aujourd'hui je dois modifier la référence de la version précédente (du coup c'est l'actuel head) car de nouveaux fichiers sont arrivés (geonature a évolué) et je souhaite logiquement mettre à jour mon fichier pour éviter un conflit (déjà vu car les test de la PR bloque sur la DB).
La commande geonature db current me renvoi :
72f227e37bdf (effective head)
ca052245c6ec (head)
7d6e98441e4c (head)
3fe8c07741be (head)
21f661247023 (head)
62e63cd6135d (effective head)
829a376daa52 (head)
fa5a90853c45 (effective head)
3d0bf4ee67d1 (effective head)
2984569d5df6 (effective head)
d02f4563bebe (effective head)
681306b27407 (head)
9445a69f2bed
b820c66d8daa (head)
586613e2faeb (head)
805442837a68 (head)
f63a8f44c969 (head)
4fb7e197d241
944072911ff7 (head)
f5436084bf17 (effective head)
1715cf31a75d (effective head)
f61f95136ec3 (effective head)
3fdaa1805575 (effective head)
3842a6d800a0 (effective head)
0dfdbfbccd63 (head)
8222017dc3f6 (head)
cce08a64eb4f (head)
a763fb554ff2 (effective head)
ede150d9afd9 (head)
10e87bc144cd (head)
96a713739fdd (effective head)
7dfd0a813f86 (head)
05a0ae652c13 (effective head)
Cet état actuel de ma DB (les numéros) ne m'évoque rien même si je pense que ce sont des numéro de révisions pour des branches, mais je ne sais pas quelle(s) branche(s).
Comment comparer et bien interpréter cette liste pour savoir si je suis dans la dernière version ?
Dois-je rebase un fichier de migration, est-il mieux de le refaire après un geonature db update pour avoir les bons numéros de version et refaire ensuite le fichier ?
Merci.
Si je regarde avec un geonature db heads je vois :
ca052245c6ec (geonature) (head)
La doc indique que c'est la révision actuelle.
Mon fichier indique Revision ID: 829a376daa52 qui est donc la version (révision) de mon fichier.
D'après la commande précédente (geonature db current) :
72f227e37bdf (effective head)
ca052245c6ec (head)
7d6e98441e4c (head)
3fe8c07741be (head)
21f661247023 (head)
62e63cd6135d (effective head)
829a376daa52 (head)
Mon ID de révision est 7 ID versions avant l'ID de geonature (head).
Donc je suis en bien retard de 2 révisions. Quelle est la bonne pratique ensuite ?
geonature db current affiche la révision actuelle de chaque branche ; il ne s’agit pas d’une liste de révisions successives, qui est elle donnée par geonature db history. Pour savoir à quelle branche correspond chaque révision, tu peux utiliser geonature db show <rev-id>.
On voit que ta révision 829a376daa52 est en tête de la branche GeoNature puisqu’elle porte le drapeau (head).
Cependant, il est possible que tu n’ais pas appliqué certaines évolutions à ta base de données en ayant modifié ton fichier de révision de A à 095da7bc6667, du coup il te manque probablement les évolutions entre A et 095da7bc6667. Tu peux visualiser le code SQL associé avec geonature db upgrade --sql A:095da7bc6667. Tu peux les appliquer avec geonature db stamp A && geonature db upgrade geonature@095da7bc6667 && geonature db stamp 829a376daa52.
Pour éviter ce genre de soucis à l’avenir, il vaut mieux downgrade jusqu’à A (dé-appliquer ta révision), là la modifier pour faire pointer sur la nouvelle head, puis re-upgrader.
il vaut mieux downgrade jusqu’à A (dé-appliquer ta révision), là la modifier pour faire pointer sur la nouvelle head, puis re-upgrader.
Merci @bouttier pour le retour, ca reviendrai à faire un rebase manuellement donc.
J'ai vu qu'une commande merge existe dans le cas de plusieurs heads (ce qui m'arrive aussi) :
alembic merge heads -m "merge D and F"
https://blog.jerrycodes.com/multiple-heads-in-alembic-migrations/
Je n'ai pas testé.
En effet, Alembic fournit une fonctionnalité de merge. On l’a utilisé une fois pour le moment, pour merger des évolutions de la develop et des releases correctives de la branche 2.9. Cependant, cela réduit la lisibilité de l’historique des évolutions de la base de données, donc à éviter de faire à chaque PR de préférence.
Cependant, tu peux tout-à-fait utiliser cette fonctionnalité pour te mettre à jour : tu modifies ta révision pour lui indiquer 2 ancêtres (tu rajoutes la nouvelle head - elle devient donc un merge), tu upgrade (les révisions qui te manquais sont alors appliquées), puis tu re-définie un unique ancêtre, l’head « officiel », de manière à merger un historique facilement lisible.
À comparer, c’est sans doute un processus de rebase plus simple que les méthodes que j’ai évoquées précédemment :+1: .
Je vais rajouter un paragraphe dans la documentation sur la gestion des rebases pour clarifier ce soucis et indiquer comment s’en sortir.