Zum Inhalt springen
Anjunar/ DOCS

Bestehende Datenbanken

Zwei Wege in die Historie: eine Datenbank übernehmen, die schon passt, und eine von Hand migrierte Änderung annehmen.

Übernehmen

Eine Datenbank ohne Historie

Eine Datenbank, die hbm2ddl angelegt hat, hat keine Historie und wird standardmäßig abgelehnt. Mit adoptExistingSchema trägt der Executor sie ohne DDL als Revision 1 ein, aber nur, wenn jede Tabelle und Sequenz des Ziels existiert und die Datenbank genau passt.

properties
hibernate.ddl_manager.adopt_existing_schema=true
scala
ExecutionOptions(adoptExistingSchema = true)
Constraint-Namen

Der eine häufige Unterschied

Hibernate benennt Enum-CHECK-Constraints nach PostgreSQL-Art, das Framework nach einem Hash der Spalten-ID. Die Ablehnung nennt beide Namen; benenne den Constraint um und starte erneut.

sql
ALTER TABLE "public"."letter" RENAME CONSTRAINT "letter_status_check" TO "<name from the refusal>";

Der Executor vergleicht auch die Definition jedes Checks; ein umbenannter Constraint besteht nur, wenn er genau die modellierten Werte erzwingt. position >= 0 einer @OrderColumn weicht vom modellierten Bereich ab und muss ersetzt werden.

Manuelle Migration

Änderungen, die der Executor nicht planen kann

Typ- und Primärschlüsseländerungen und andere brauchen eine Datenmigration und werden abgelehnt. Die Ablehnung nennt den Fingerprint des Ziels. Migriere die Datenbank von Hand genau auf das Ziel und starte einmal mit diesem Fingerprint.

scala
ExecutionOptions(acceptManualMigration = Some("9d4c1e7a52b8f03c6e1d9a47b2c85f10e3a6d7c94b1f2e08c5a3d6b9e7f40c21"))
Was der Executor prüft
Die Datenbank entspricht dem Ziel, unter der Sperre.
Alles, was das Ziel gelöscht oder umbenannt hat, ist unter dem alten Namen verschwunden.
Dann wird das Ziel als nächste Revision eingetragen, Status ManuallyMigrated, ohne DDL.
Eine Option mit einem anderen Ziel wird abgelehnt; sie kann keine spätere Änderung versehentlich annehmen.