Toolgestütztes Datenbank-Refactoring

Flyway

Flyway nutzt ein Konzept von sechs verschiedenen Befehlen, um die Funktionalität rund um das Datenbank-Refactoring zu realisieren. Diese Befehle können entweder über die Kommandozeile, aus einem Buildprozess − etwa Maven oder Gradle − oder direkt aus dem Java-Code aufgerufen werden. Als Eingabe werden diesen Befehlen jeweils die Verbindungsdaten zur gewünschten Datenbank mitgegeben.

Der Hauptbefehl heißt “migrate” und macht genau das, worum es beim Datenbank-Refactoring geht: Er schaut in einem bestimmten Ordner nach, welche Datenbankskripte verfügbar sind, prüft, welche von diesen Skripten bereits auf der Zieldatenbank ausgeführt wurden und führt diejenigen aus, die noch nicht ausgeführt wurden. Im Falle einer Inkonsistenz − also wenn beispielsweise ein Skript in der Zwischenzeit verändert wurde − bricht Flyway die Verarbeitung ab.

Ein spannendes Feature von Flyway ist, dass Datenbankskripte nicht nur in SQL-Form vorliegen können, sondern auch als Java-Code. Mit Unterstützung von JDBC könnt ihr damit auch komplexere und dynamische Datenbankänderungen durchführen. Allerdings solltet ihr dieses Feature mit Bedacht nutzen, da es aufgrund der dynamischen Änderungen die Verfolgbarkeit von Fehlern erschwert.

Neben dem Befehl “migrate” steht euch eine Reihe von weiteren Hilfsbefehlen zur Verfügung. Der Befehl “info” zeigt euch, welche Migrationsskripte wann aufgerufen wurden und welche noch ausstehen.

Mit dem Befehl „validate“ prüft ihr, ob die Datenbankskripte auch in der richtigen Version eingespielt wurden. Dieser schlägt Alarm, wenn zum Beispiel ein Datenbankskript nach dem Einspielen nachträglich geändert wurde, da dies zu unterschiedlichen Schemaständen auf unterschiedlichen Zieldatenbanken führen könnte.

Möchtet ihr die Skripte trotz eines fehlgeschlagenen validate-Befehls ausführen, könnt ihr zuvor auf den Befehl “repair” zurückgreifen. Dieser modifiziert die Datenbanktabelle mit dem Namen SCHEMA_VERSION und zwar in der Tabelle, in der hinterlegt ist, welche Skripte wann ausgeführt wurden. Außerdem passt er sie an den Stand der gerade vorliegenden Skripte an.

Wenn ihr eine bestehende Datenbank habt, die ab sofort mit Flyway versioniert werden soll, habt ihr die Option, den Befehl “baseline” zu nutzen. Damit erzeugt ihr die von Flyway genutzte Datenbanktabelle SCHEMA_VERSION, um ab sofort Metadaten zu den ausgeführten Skripten zu speichern.

Der “clean”-Befehl leert letztendlich eine Datenbank vollständig und ist offensichtlich nur für Testsysteme gedacht.

Liquibase

Liquibase verfolgt einen anderen Ansatz zum Datenbank-Refactoring als Flyway. Während Flyway Datenbankänderungen nur in Form von SQL- und Java-Skripten ermöglicht, könnt ihr mit Liquibase eine vollständige Entkopplung des verwendeten Datenbankprodukts erreichen.

An Stelle von SQL-Skripten könnt ihr nämlich auch Skripte im XML-, YAML- oder JSON-Format zur Verfügung stellen, in denen ihr die Möglichkeit habt, auf einem abstrakten Level Änderungen an der Datenbank zu definieren. Für jedes dieser Formate gibt es eine Notation für sogenannte “Changes”. Der “CREATE TABLE”-Change erzeugt beispielsweise eine neue Tabelle und sieht im YAML-Format in etwa so aus:

Analog steht euch „Changes“ zur nachträglichen Änderung einer Tabelle – beispielsweise “ADD COLUMN”, “CREATE INDEX” oder “ALTER TABLE” – zur Verfügung. Ähnlich wie Flyway führt auch Liquibase alle noch nicht ausgeführten Skripte in einem bestimmten Ordner aus und speichert die Metadaten der ausgeführten Skripte in einer eigenen Datenbanktabelle. Genauso wie Flyway kann der Prozess über die Kommandozeile oder aus dem Java-Code heraus aufgerufen werden.

Fazit

Sowohl Flyway als auch Liquibase bieten euch sämtliche Funktionen, die benötigt werden, um eine Datenbank kontrolliert zu verändern und zwar so, dass ihr jederzeit wisst, in welcher Version des Datenbankschemas ihr euch momentan befindet. Beide Werkzeuge lassen sich gut in Maven- oder Gradle-Buildprozesse integrieren. Darüber hinaus werden beide Tools von Spring Boot als Anwendungsplattform unterstützt. Somit müsst ihr euch gar nicht mehr selbst um die Ausführung der Skripte kümmern. Während Flyway auf SQL-Skripte setzt, die genau auf das Zieldatenbanksystem – wie beispielsweise Oracle oder PostgreSQL − zugeschnitten sind, bietet euch Liquibase die Möglichkeit vom verwendeten Datenbanksystem zu abstrahieren. Liquibase sollte daher das Tool eurer Wahl sein, wenn es um die Entwicklung eines Softwareproduktes geht, das in verschiedenen Installationen mit unterschiedlichen Datenbanksystemen arbeiten soll. Möchtet ihr dagegen mehr Kontrolle über die Datenbankänderungen haben, solltet ihr Flyway wählen, um die Datenbank mit zugeschnittenen SQL-Skripten oder gar ausprogrammierten Java-Skripten zu verändern.

Der Haken an beiden Tools ist allerdings, dass sie hauptsächlich von einer Person und nicht von einem großen Team genutzt werden können. Die Aktivität der Entwicklung ist bei Flyway aber deutlich höher als bei Liquibase. Bei Letzterem hat sich nämlich seit fast einem halben Jahr nichts mehr getan hat.

Hier gelangt ihr zum letzten Blog-Beitrag.