Dans cet article, nous parlerons de Flyway et Liquibase , les deux outils de refactoring de base de données Java les plus populaires. Le but de l'article est de comparer ces outils et de savoir lequel est préférable d'utiliser dans quels cas.
Flyway
Le concept Flyway est centré sur six équipes différentes pour prendre en charge la refactorisation et le versionnage automatisés des bases de données. Ces commandes peuvent être exécutées à partir de la ligne de commande, pendant le processus de génération (produites à l'aide de Maven ou Gradle), ou directement à partir du code Java à l'aide d'appels d'API. Lors de l'exécution de ces commandes, vous devez fournir les paramètres de connexion à la base de données (URL, nom d'utilisateur, mot de passe) que vous souhaitez refactoriser.
La commande principale s'appelle migrate et exécute une fonction qui contient toute l'essence du refactoring de base de données: elle scanne un dossier spécial avec des scripts sql (dont chacun a un numéro de version dans le nom du fichier) et vérifie lesquels d'entre eux ont déjà été appliqués à la base de données cible. Il exécute ensuite ceux d'entre eux qui n'ont pas encore été appliqués à cette base de données. En cas de conflit, par exemple, si le script déjà appliqué a changé depuis son utilisation, Flyway interrompt son fonctionnement avec un message d'erreur.
Une caractéristique unique de Flyway est que les scripts de migration peuvent être non seulement au format SQL, mais également sous forme de code Java. La deuxième option vous permet d'implémenter des migrations dynamiques avec une logique complexe. Cependant, vous devez utiliser l'approche Java avec prudence, car ces scripts de migration sont généralement difficiles à déboguer en cas de problème.
En plus de la commande principale de migrate , Flyway dispose de commandes supplémentaires qui facilitent le processus de refactorisation de la base de données.
La commande info affiche tous les scripts de migration disponibles à partir d'un dossier donné et note lesquels d'entre eux ont déjà été utilisés et lesquels ne seront appliqués qu'à la base de données cible.
Pour vérifier si les scripts appliqués à la base de données ont changé, la commande validate est utilisée. Il est utile pour nous de savoir si le script déjà appliqué du dossier a été modifié depuis qu'il a été appliqué à la base de données, car cela peut signifier que le script a été appliqué à différentes bases de données dans différentes versions, ce qui peut entraîner des problèmes.
Si vous pensez que les scripts doivent être utilisés malgré l'échec indiqué par la commande validate, vous pouvez exécuter la commande repair. Il réinitialisera la table de base de données utilisée par Flyway pour corriger les scripts qui ont déjà été appliqués (par défaut, cette table est appelée SCHEMA_VERSION).
Et la dernière commande, mais non moins importante, clean efface complètement le schéma sélectionné (comme vous le savez, cette commande ne doit être utilisée que pour les bases de données de test).
Liquibase
Liquibase adopte une approche différente pour implémenter le refactoring de base de données. Contrairement à Flyway, qui prend en charge les scripts de migration uniquement aux formats SQL et Java, Liquibase vous permet d'abstraire de SQL et ainsi de supprimer la refactorisation de la base de données de son implémentation spécifique.
Au lieu des scripts SQL, Liquibase prend en charge les scripts de migration aux formats XML, YAML et JSON. Dans ces scripts, vous définissez les modifications apportées à la base de données au niveau de l'abstraction. Pour chaque modification, Liquibase a un élément correspondant en XML, YAML et JSON. Par exemple, une modification qui crée une nouvelle table de base de données au format YAML ressemble à ceci:
createTable: tableName: Customer columns: - column: name: name type: varchar(255) - column: name: address type: varchar(255)
Les modifications telles que l' add column , la create index ou la alter table et d'autres, se ressemblent.
Pendant le fonctionnement, Liquibase applique automatiquement tous les scripts qui n'ont pas encore été utilisés et, comme Flyway, enregistre leurs métadonnées dans une table de base de données spéciale. Comme Flyway, Liquibase peut être invoqué depuis la ligne de commande des outils de build ou directement via son API Java.
Quand les utiliser?
Flyway et Liquibase prennent en charge toutes les fonctions nécessaires à la refactorisation et au versionnage professionnels de la base de données, de sorte que vous saurez toujours à quelle version du schéma de base de données vous avez affaire et si elle correspond à la version de votre logiciel. Les deux outils sont intégrés à Maven et Gradle et à l'écosystème Spring Boot, de sorte que le refactoring de la base de données peut être entièrement automatisé.
Flyway utilise SQL pour identifier les modifications de base de données, vous pouvez donc configurer des scripts SQL pour fonctionner efficacement avec des types spécifiques de bases de données sur votre projet, comme Oracle ou PostgreSQL. D'un autre côté, Liquibase introduit un niveau d'abstraction supplémentaire en utilisant XML, YAML ou JSON pour détecter les modifications de la base de données. Ainsi, Liquibase est mieux adapté aux logiciels qui doivent être installés dans différents environnements avec différents types de serveurs de base de données. Cependant, si vous avez besoin d'un contrôle total sur votre SQL, Flyway est votre choix, car il vous permet de modifier la base de données en utilisant un SQL entièrement personnalisé ou même en utilisant du code Java.
Le hic avec les deux outils est qu'ils sont soutenus par une seule personne (du traducteur: selon l'auteur) , et non par une grande équipe. Cela peut avoir un impact négatif sur le développement futur des deux outils, mais ce n'est pas nécessaire. Au moment d'écrire ces lignes , l'activité dans le référentiel Flyway GitHub est plus élevée que dans le référentiel Liquibase .