Wie im Flug

Datenbanken-Migration: Flyway 5.1 erschienen

Marcel Richters
Flyaway

© Shutterstock / frankie’s

 

Datenbanken zu migrieren ist nicht gerade leicht, aber darum gibt es Tools, die dabei helfen. Mit Flyway 5.1 hat eines dieser Tools jetzt ein Update bekommen. Dabei wurde einiges an Support hinzugefügt, für die Premium-Versionen der Open-Source-Anwendung gibt es noch einige Neuerungen mehr.

Das Datenbanken-Migrationstool Flyway hat sein erstes größeres Update seit Version 5.0 erhalten. Flyway 5.1.0 bringt vor allem neuen und aktualisierten Support für diverse Datenbanken. Aber nicht nur.

Das ist neu

Flyway unterstützt ab sofort die Datenbanken in ihren aktuellen Versionen: CockroachDB 2.0, MySQL 8.0 und Informix 12.10. Außerdem wird jetzt Java 10 unterstützt.

Aufgrund der erweiterten Möglichkeiten, die mit neuen unterstützten Datenbanken einhergehen, haben sich die Entwickler entschlossen, die Callbacks zu überarbeiten. So gibt es vollständig neue Java-basierte Callbacks im jetzt hinzugefügten org.flywaydb.core.api.callback.Callback-Interface:

/**
 * This is the main callback interface that should be implemented to handle Flyway lifecycle events.
 */
public interface Callback {
    /**
     * Whether this callback supports this event or not. This is primarily meant as a way to optimize event
     * handling by avoiding unnecessary connection state setups for events that will not be handled anyway.
     *
     * @param event   The event to check.
     * @param context The context for this event.
     * @return {@code true} if it can be handled, {@code false} if not.
     */
    boolean supports(Event event, Context context);

    /**
     * Whether this event can be handled in a transaction or whether it must be handled outside a transaction
     * instead. In the vast majority of the cases the answer will be {@code true}. Only in the rare cases 
     * where non-transactional statements are executed should this return {@code false}.
     * This method is called before {@link #handle(Event, Context)} in order to determine in advance whether
     * a transaction can be used or not.
     *
     * @param event   The event to check.
     * @param context The context for this event.
     * @return {@code true} if it can be handled within a transaction (almost all cases). {@code false} if it
     * must be handled outside a transaction instead (very rare).
     */
    boolean canHandleInTransaction(Event event, Context context);

    /**
     * Handles this Flyway lifecycle event.
     *
     * @param event   The event to handle.
     * @param context The context for this event.
     */
    void handle(Event event, Context context);
}

Mit dieser Überarbeitung sollen Events wie Ausfallbedingungen und Vorfälle, bei denen Callbacks nicht mehr transaktionsbezogen ausgeführt werden können, besser gehandhabt werden können.

Der implementierte SQL-basierte Callback wurde schon angepasst, um diese Möglichkeit übergangslos zu nutzen. So stellt Flyway automatisch fest, ob ein SQL-Callback ein SQL-Statement enthält, welches in der Transaktion nicht ausgeführt werden kann und sollte dann den Callback außerhalb der Transaktion durchführen.

Zusätzlich können jetzt mehrere SQL-basierte Callbacks im selben Lifecycle-Event ausgeführt werden. Wenn mehr als ein SQL-Callback für ein Event aktiv ist, ordnet Flyway diese automatisch nach ihrer Beschreibung. Existierende Interfaces sind zwar jetzt veraltet, aber Java-basierte Callbacks werden noch bis Flyway 6.0 unterstützt.

Konfigurationen

API-Nutzer können Flyway jetzt sich selbst konfigurieren lassen, das Tool nutzt dafür Umgebungsvariablen. Daneben wurde das configurations-Interface überarbeitet. Diesem wurden FluentConfiguration für fluente Konfigurationen und ClassicConfigurationfür Konfigurationen im JavaBean-Stil hinzugefügt.

Weitere Neuerungen im Support für Flyway Pro

Die folgenden Änderungen beziehen sich nur auf mindestens Flyway Pro, also die „kleine“ kommerzielle Version des Programms. Daneben gibt es noch Flyway EE für Unternehmen.

In beiden Versionen ist jetzt ein flyway.batch-Flag enthalten. Damit soll Flyway automatisch DML-Statements erkennen und deren Ausführung bündeln. Die Entwickler versprechen dadurch bis zu 99% weniger Round-Trips im Netzwerk.

Mit dem flyway.stream-Flag soll der Speicherverbrach drastisch reduziert werden. Denn Flyway erkennt so, ob eine SQL-Migration aus dem Dateisystem größer als 16 kB ist. Wenn dies der Fall ist, wird die Migration transparent gestreamt, anstatt sie vollständig zu laden.

Ein drittes Flag, nämlich flyway.oracle.sqlplus, wurde erweitert. So bearbeitet Flyway jetzt bei der Arbeit mit Oracle SQL*Plus folgende Befehle automatisch:

  • DEFINE
  • UNDEFINE
  • SET DEFINE
  • SET SCAN

Damit bearbeitet Flyway SQL*Plus-&my_var-Platzhalter mit voller Unterstützung für definierte und undefinierte Werte direkt im Migrationsscript. Außerdem wird das Define-Symbol von & zu einem selbst gewählten.

Für die Auflösung von Platzhaltern nutzt Flyway den eigenen Placeholder-Store ebenso wie den von SQL*Plus.

Zusätzlich dazu gibt es noch diverse weitere Änderungen und Bugfixes. Genaue Informationen dazu finden sich in den Release Notes. Inzwischen ist auch Version 5.1.1. mit mehreren kleineren Fehlerbehebungen erschienen.

Geschrieben von
Marcel Richters
Marcel Richters
Marcel hat Soziologie an der Goethe-Universität in Frankfurt am Main studiert und danach als E-Commerce-Manager gearbeitet. Seit Februar 2018 unterstützt er das Team von JAXenter als Redakteur. Daneben arbeitet er als freier Journalist in der Mainmetropole.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: