Kombinieren Hibernate automatische Schema Erstellung und Datenbank Versionierung

Question

Ich habe eine Anwendung, wo Hibernate alle meine Tabellenschemata erstellt, wenn die Anwendung zum ersten Mal auf einer Maschine ausgeführt wird. Das funktioniert gut.

Nun habe ich mich gefragt, ob Hibernate einen Mechanismus hat, um die Datenbank unter Versionskontrolle zu halten, dh Hibernate weiß, wie man ein Schema in ein anderes migriert, wenn ich eine andere Version meiner Anwendung ausführe und Hibernate eine andere Datenbank findet Schema von einer älteren Version vorhanden? Ich denke, irgendwie, dass dies möglich sein sollte, wenn man bedenkt, dass Hibernate das bestehende Schema lesen und konnte das Schema der Abbildung Beschreibung vergleichen. Ich würde jedoch nicht wissen, wie ich Hibernate sagen könnte, alte Daten zu migrieren, wie beim Erstellen von Änderungsskripten mit z. Liquibase/Flugweg.

Ich habe vielleicht nicht die richtigen Dinge googled seit Hibernate und Versionierung wird Ihnen eine Menge von Hits auf Auditing und Feldversionierung zeigen, aber ich denke mehr in Bezug auf Liquibase/Flyway Art der Versionierung. Ich hielt nie beide zusammen, aber da Hibernate keine Update-Skripte erstellen, sondern manipuliert direkt auf die Datenbank, würde ich nicht wissen, wie das machen beide zusammen arbeiten.

Dies ist das erste Mal, dass ich Hibernate mein Schema erstellen lassen, anstatt meine eigenen Skripte zu schreiben. Ich tue dies, um den Einsatz von Hibernate Envers zu machen, was die Schaffung zusätzlicher mühsam die manuelle Skripts macht. Vielleicht vermisse ich etwas Offensichtliches. Vielen Dank für Ihre Anregungen!

Update: Ich habe heute mit dem Entwickler von Flyway gesprochen und er sagte mir, dass er keine gute Lösung wissen würde. Vielleicht gibt es nichts?

Answer 1

Wir hatten das gleiche Problem mit unserem Java/Hibernate-Projekt und wollten keinen Code kopieren. Hibernate "update" -Funktion ist überhaupt nicht zuverlässig, LiquidBase ist besser, aber nicht 100% narrensicher. Am Ende haben wir ein einfaches Skript, das folgende Verfahren zu verwalten:

1. Das „aktuelle“ Datenbank-Schema immer von Hibernate erzeugt wird, gegen eine DEV-Datenbank direkt.
2. Ein "vorheriges" Datenbankschema ist , das von einer Reihe von LiquiBase-Änderungssätzen generiert wird.
3. Jedes Mal, wenn eine Migration benötigt wird, wird ein Liquibase „diff“ -Funktion zwischen der „Zurück“ und „aktuelle“ Datenbanken aufgerufen (zwei aktuellen Datenbanken, ja, zuverlässiger auf diese Weise), einen neue Liquibase Änderungsset Erzeugen .
4. Diese Änderungsset muss manuell überprüft werden. Alle Änderungssätze werden in der Quellcodeverwaltung beibehalten.
5. Für die Datenbank PRODUCTION wird das Schema generiert, indem alle LiquiBase-Änderungssätze angewendet werden.

Ein Tastenbefehl in unserem Skript liest sich wie folgt zusammen:

${LIQB_COMMAND} ${PREV_DB_OPTIONS} --changeLogFile=${LIQB_CHGLOG_FILE_NEW} \ 
    diffChangeLog \ 
       --referenceUsername=${DEV_DB_USER} \ 
       --referencePassword=${DEV_DB_PWD} \ 
       --referenceDriver=com.mysql.jdbc.Driver \ 
       --referenceUrl=${DEV_DB_URL} 

Auf diese Weise unsere Migrationsprozess recht zuverlässig ist und Sie das Schema Code zweimal nicht schreiben. Es gibt eine manuelle Überprüfung der erzeugten Änderung in XML gesetzt, aber die meiste Zeit ist es kein Problem, und es sicher ist viel einfacher als manuell die Schemaänderung Schreiboperationen.