2017-10-10 2 views
1

J'utilise actuellement l'outil Ligne de commande Flyway pour gérer nos scripts qui seront appelés via notre processus de lancement déclenché à partir de notre serveur CI Build. Le problème est que j'ai 274 migrations répétables couvrant les spécifications de l'emballage, les corps de l'emballage, les fonctions, les procédures, les vues et les vues matérialisées. Quand je lance migrer tout fonctionne comme prévu avec les migrations exécutées suivies de toute migration répétable changée mais disons dans la prochaine version que nous voulons supprimer un objet que l'une des migrations répétables maintient. Par exemple, nous voulons supprimer le script répétable qui a défini ProcedureOne (c'est-à-dire R__ProcedureOne.sql). Pour ce faire, j'aurais un nouveau script de migration (V3.1.5.1.01__DropProcedureOne.sql) mais je supprimerais aussi le script de migration répétable afin que l'objet ne soit pas créé et maintenu. Toutefois, l'exécution de l'info-bulle affiche le script R__ProcedureOne.sql avec le statut MISSING. Bien que je sois d'accord qu'il manque, il est une action délibérée de l'avoir supprimé car il n'est plus nécessaire d'être déplacé.Quel est le meilleur moyen de supprimer des scripts répétables de Flyway Migrations

Je suis conscient de l'option migrate ignoreMissingMigrations mais je pense que l'utilisation de cette option présente un risque et pourrait masquer les fichiers manquants.

Quelle est la directive générale sur la meilleure façon de supprimer un script répétable?

Répondre

0

Je vous suggère de conserver simplement le fichier mais de le rendre vide (zéro octet). Vous pouvez également ajouter un commentaire dans le fichier qui explique que l'objet qu'il représente a été supprimé. En ce qui concerne l'effacement réel, une autre option de ce que vous avez suggéré pourrait être de mettre à jour la migration répétable pour la supprimer elle-même, puis de la mettre à nouveau à zéro. Cela a l'avantage de pouvoir être rejoué dans une base de données vide; Puisque les migrations répétables sont appliquées après la version, la procédure dans votre exemple n'existera pas pour être supprimée. L'inconvénient est l'exécution de deux migrations.

+0

Merci pour la réponse. Quelques options intéressantes. J'aime avoir le script versionné indépendant pour abandonner la procédure, mais je ne sais pas exactement ce que je ressens à l'idée de laisser le script reproductible là pour l'éternité même s'il est vide. J'ai juste envie de laisser derrière moi un fouillis. Que pensez-vous de la modification du contenu de la table schema_version? Le script drop proc pourrait supprimer toutes les références au script repeatable (non essayé donc ne sais pas si cela fonctionnerait) – cdavid15

+0

Avez-vous besoin de reproduire la base de données en exécutant des scripts à partir de la version 1? Si ce n'est pas le cas, vous pouvez prendre quelques libertés avec l'historique conservé dans la table schema_version. Je ne recommanderais pas cela car vous perdez l'historique d'audit créé par Flyway pour vous. Vous devez essayer comment l'obtenir car Flyway peut verrouiller la table schema_version en cours d'exécution. Je suggère de copier les enregistrements à une autre table pour garder l'historique –