Annulation des migrations avec Flyway

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 migrate

2.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 migrate

Enfin, nous pouvons vérifier l'historique de toutes les migrations en utilisant:

./flyway info

ce 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 info

Cela 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 migrate

Lorsqu'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 undo

Une fois la commande exécutée avec succès, nous pouvons à nouveau vérifier l'état des migrations:

./flyway -pro info

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