1. Introduction
Dans ce court didacticiel, nous explorerons quelques façons d'annuler une migration avec Flyway.
2. Simuler la restauration avec une migration
Dans cette section, nous allons restaurer notre base de données à l'aide d'un fichier de migration standard.
Dans nos exemples, nous utiliserons la version en ligne de commande de Flyway. Cependant, les principes de base sont également applicables aux autres formats, tels que l'API de base, le plugin Maven, etc.
2.1. Créer une migration
Tout d'abord, ajoutons une nouvelle table de livre à notre base de données. Pour ce faire, nous allons créer un fichier de migration appelé V1_0__create_book_table.sql :
create table book ( id numeric, title varchar(128), author varchar(256), constraint pk_book primary key (id) );Deuxièmement, appliquons la migration:
./flyway migrate2.2. Simuler la restauration
Puis, à un moment donné, disons que nous devons inverser la dernière migration.
Afin de restaurer la base de données avant la création de la table de livre , créons une migration appelée V2_0__drop_table_book.sql :
drop table book;Ensuite, appliquons la migration:
./flyway migrateEnfin, nous pouvons vérifier l'historique de toutes les migrations en utilisant:
./flyway infoce qui nous donne le résultat suivant:
+-----------+---------+-------------------+------+---------------------+---------+ | Category | Version | Description | Type | Installed On | State | +-----------+---------+-------------------+------+---------------------+---------+ | Versioned | 1.0 | create book table | SQL | 2020-08-29 16:07:43 | Success | | Versioned | 2.0 | drop table book | SQL | 2020-08-29 16:08:15 | Success | +-----------+---------+-------------------+------+---------------------+---------+Notez que notre deuxième migration s'est déroulée avec succès.
En ce qui concerne Flyway, le deuxième fichier de migration n'est qu'une autre migration standard. La restauration proprement dite de la base de données vers la version précédente se fait entièrement via SQL. Par exemple, dans notre cas, le SQL de suppression de la table est l'opposé de la première migration, qui crée la table.
En utilisant cette méthode, la piste d'audit ne nous montre pas que la deuxième migration est liée à la première , car ils ont des numéros de version différents. Afin d'obtenir une telle piste d'audit, nous devons utiliser Flyway Undo.
3. Utilisation de Flyway Undo
Tout d'abord, il est important de noter que Flyway Undo est une fonctionnalité commerciale de Flyway et n'est pas disponible dans l'édition communautaire. Par conséquent, nous aurons besoin de l'édition Pro ou de l'édition Entreprise pour utiliser cette fonctionnalité.
3.1. Créer des fichiers de migration
Commençons par créer un fichier de migration appelé V1_0__create_book_table.sql :
create table book ( id numeric, title varchar(128), author varchar(256), constraint pk_book primary key (id) );Deuxièmement, créons le fichier de migration d'annulation correspondant U1_0__create_book_table.sql :
drop table book;Dans notre migration d'annulation, notez comment le préfixe de nom de fichier est «U» par rapport au préfixe de migration normal de «V». De plus, dans nos fichiers de migration d'annulation, nous écrivons le SQL qui annule les modifications du fichier de migration correspondant . Dans notre cas, nous supprimons la table créée par la migration normale.
3.2. Appliquer les migrations
Ensuite, vérifions l'état actuel des migrations:
./flyway -pro infoCela nous donne le résultat suivant:
+-----------+---------+-------------------+------+--------------+---------+----------+ | Category | Version | Description | Type | Installed On | State | Undoable | +-----------+---------+-------------------+------+--------------+---------+----------+ | Versioned | 1.0 | create book table | SQL | | Pending | Yes | +-----------+---------+-------------------+------+--------------+---------+----------+ Notez la dernière colonne, Undoable , qui indique que Flyway a détecté un fichier de migration d'annulation qui accompagne notre fichier de migration normal.
Ensuite, appliquons nos migrations:
./flyway migrateLorsqu'elle est terminée, nos migrations sont terminées et notre schéma a une nouvelle table de livre:
List of relations Schema | Name | Type | Owner --------+-----------------------+-------+---------- public | book | table | baeldung public | flyway_schema_history | table | baeldung (2 rows) 3.3. Annuler la dernière migration
Enfin, annulons la dernière migration en utilisant la ligne de commande:
./flyway -pro undoUne fois la commande exécutée avec succès, nous pouvons à nouveau vérifier l'état des migrations:
./flyway -pro infoce qui nous donne le résultat suivant:
+-----------+---------+-------------------+----------+---------------------+---------+----------+ | Category | Version | Description | Type | Installed On | State | Undoable | +-----------+---------+-------------------+----------+---------------------+---------+----------+ | Versioned | 1.0 | create book table | SQL | 2020-08-22 15:48:00 | Undone | | | Undo | 1.0 | create book table | UNDO_SQL | 2020-08-22 15:49:47 | Success | | | Versioned | 1.0 | create book table | SQL | | Pending | Yes | +-----------+---------+-------------------+----------+---------------------+---------+----------+Remarquez comment l'annulation a réussi et la première migration est de retour en attente. De plus, contrairement à la première méthode, la piste d'audit montre clairement les migrations qui ont été annulées.
Bien que Flyway Undo puisse être utile, cela suppose que l'ensemble de la migration a réussi. Par exemple, cela peut ne pas fonctionner comme prévu si une migration échoue en cours de route.
4. Conclusion
Dans ce court didacticiel, nous avons examiné la restauration de notre base de données à l'aide d'une migration standard. Nous avons également examiné la manière officielle de restaurer les migrations à l'aide de Flyway Undo. Comme d'habitude, tout notre code lié à ce tutoriel peut être trouvé sur GitHub.