Sobald wir einen Prototypen deployt haben (siehe #13 (closed)) und spätestens in Produktion werden wir nicht mehr bei jedem Neustart der Anwendung das Datenbank-Schema und sämtliche Daten wegwerfen und neu anlegen können. Wir sollten also frühzeitig darüber nachdenken, wie wir künftig mit Schemaänderungen umgehen.
Die wichtigsten Punkte dabei sind:
- Identische Schemas in Dev- und Produktionsdatenbanken
- Nachvollziehbarkeit der Änderungen (am Besten mit Versionsnummern)
- Verlässliche Umstellung des Schemas
- Möglichst wenig Handarbeit, abgesehen von der Schema-Definition
Es gibt mindestens drei Möglichkeiten, das Problem zu lösen:
- Hibernate mittels
spring.jpa.hibernate.ddl-auto=update
- Flyway
- Liquibase
Hibernate
➕ Kein zusätzliches Tool
➖ Primär für Entwicklungs-Datenbanken gedacht (siehe hier)
➖ Keine Versionierung (nach kurzer Recherche, evtl. nochmal gründlicher schauen)
Flyway
➕ Erfüllt alle Anforderungen (Pro Migration eigene .sql-Datei, DB-Tabelle mit History, Migrationen werden bei Bedarf automatisch angewandt)
➕ Spring-Unterstützung OOTB, Gradle-Plugin
⚪ Migrationen in nativem SQL (auch DB-spezifische Dialekte) oder Java
➖ Manche Features nur in der kostenpflichtige Version verfügbar (z.B. Undo), siehe Vergleich der Versionen - Klären: Wie wichtig sind diese Features?
➖ Zusätzliches Tool
Liquibase
➕ Erfüllt alle Anforderungen (Pro Migration eigene .sql-Datei, DB-Tabelle mit History, Migrationen werden bei Bedarf automatisch angewandt)
➕ Spring-Unterstützung OOTB, Gradle-Plugin
➕ CSV-Import (kein Auto-Rollback)
⚪ Migrationen in nativem SQL (auch DB-spezifische Dialekte), XML, JSON oder YAML
⚪ Kommerzielle Version (Datic) verfügbar mit mehr Features, Rollback geht aber so, siehe Vergleich der Versionen
➖ Zusätzliches Tool