Rollback to tag ne fonctionne pas si tag appliqué à runOnChange changeset

Question

J'ai été capable d'effectuer un rollback pour étiqueter avec seulement des modifications de schéma, mais j'ai rencontré un scénario qui ne fonctionne pas lorsque je mélange des procédures stockées.
J'utilise des changelogs SQL par rapport à une base de données Oracle. Voici le scénario:

presse
1.0.0 J'ai un script r-1.0.0.sql qui contient crée une table, et un proc.sql de script qui crée une procédure stockée. Le changeset proc est étiqueté comme runOnChange = true.
Je suis satisfait des changements, et j'étiquette la base de données avec l'étiquette
1.0.0 En fin de la table DATABASECHANGELOG montre:
1 - r-1.0.0.sql éxécutée
2 - proc.sql- EXECUTED- (tag) 1.0.0

2.0.0
presse J'ai un script r-2.0.0 qui renomme une colonne, et je également mis à jour proc.sql avec le nouveau nom de la colonne. Après l'exécution de ce, DATABASECHANGELOG est:
1 - r-1.0.0.sql exécuté
4 - proc.sql-RERAN- (tag) 1.0.0
3 - r-2.0.0.sql exécuté

Vous remarquerez que le script proc re-ran a un nouveau numéro, mais il conserve encore la balise

1.0.0

Si je veux rollback de marquer 1.0.0, la commande rollback ne fait rien, car étiquette 1.0.0 correspond au tout dernier changement dans le journal.

Cela semble être voulu par la conception. Existe-t-il une manière différente d'organiser mes modifications pour que cela fonctionne?

Answer 1

J'ai trouvé une solution basée sur l'article I ci-dessus. En raison de contraintes dans mon environnement, je n'avais pas de moyen facile de transmettre des variables d'environnement Java. J'ai fini par l'installation d'un fichier batch personnalisé (je l'ai appelé Liquibase-sp.bat) avec le contenu suivant:

@echo off 

IF NOT DEFINED JAVA_OPTS set JAVA_OPTS= 
set JAVA_OPTS=-Dliquibase.databaseChangeLogTableName=STOREDPROCCHANGELOG %JAVA_OPTS% 

liquibase %* 

Il définit le paramètre dans une variable utilisée par le fichier batch Liquibase, puis appelle le fichier de commandes passe toute la ligne de commande.
Pendant mon déploiement, j'applique des changements de schéma en appelant "liquibase", puis j'applique des changements de proc mémorisés en appelant "liquibase-sp". Les modifications de schéma sont enregistrées dans la table DATABASECHANGELOG par défaut, tandis que les modifications proc sont enregistrées dans une table STOREDPROCCHANGELOG distincte. Tout le marquage est fait en appelant "liquibase" donc il utilise la table par défaut, et seuls les changements de schéma sont étiquetés avec une version.

La restauration fonctionne dans le scénario que j'ai mentionné.

Je m'attends à voir un problème supplémentaire si j'ai une version 2.0.0 sans modifications. Lorsque je marque la base de données avec la version 2.0.0, la balise du dernier ensemble de modifications est modifiée de la version 1.0.0 à la version 2.0.0. Cela signifie que toute annulation de l'étiquette 1.0.0 échouerait. Je ne suis pas inquiet cependant, il y a des solutions de rechange procédurales pour cela.