H2DB Umstieg auf 2.3.x

[JohannMaierhofer]

Wegen der aktuellen Probleme mit der H2DB v.1.4.199 möchte ich eine Disskussion über einen Umstieg auf v2.3.x starten. Mir ist bewusst, dass es von v1 auf v2 keine direkte Migration gibt und darum die Entscheidung schwierig ist.

Nun zu meinen Gründen:

1. Die aktuelle Version ist schon sehr alt und wir bekommen in v1 keine Fehler korrigiert. Aber ok, solange es gut geht ist das wohl zu verschmerzen.
2. Andere Tools stellen langsam den Support der v1 ein. Ich habe gerade in Support H2 with database format v3 — v 2.2.220 dbeaver/dbeaver#20676 gelesen, dass Dbeaver bald DB Format v3 unterstützt und dafür den Support für v1 entfernt.
3. Aktuell haben wir Probleme mir der aktuellen Version. Siehe Fehler beim Speichern von Mitgliedern #208. Auch andere Benutzer im Forum berichten über dieses Problem. Viele werden es nach der Migration auf die 2.8.22 erst gar nicht merken sondern erst wenn sie ein Mitglied mit kleiner Id speichern wollen.
   Ich habe hier nochmals nachgeforscht und folgendes festgestellt:

• Migration von 2.8.21 auf 2.8.22 mit DB v.1.4.199: Der Fehler tritt reproduzierbar auf. Fehler zeigt sich mit v.1.4.199.
• Die fehlerhafte DB lässt sich mit v.1.4.196 öffnen wobei sich damit der Fehler beim Speichern der Mitglieder nicht zeigt.
• Über das beschriebene Recovery lässt sich die DB reparieren und dann tritt der Fehler mit v.1.4.199 nicht mehr auf.
• Migration von 2.8.21 auf 2.8.22 mit DB v.1.4.196: Der Fehler tritt dann weder mit DB v.1.4.196 noch mit v.1.4.199 auf.
• Das zeigt eindeutig, dass der Fehler bei der Migration mit der v.1.4.199 erzeugt wird, aber auch nur die v.1.4.199 später das Problem damit hat.

Ich habe kurz einmal einen Test mit der 2.0.206 gemacht. Diese hat noch das DB Format v2 welches noch vom aktuellen Dbeaver unterstützt wird.
Das Ergebnis für das Starten ohne DB und Anlegen einer neuen DB:

• Die Migration hat Probleme und benötigt ein paar Änderungen in AbstractDDLUpdate.java. Bei ALTER TABLE muss ein " SET DATA TYPE " dazu. Bei BIGINT muss das (19) weg. Bei Update0422.java muss bei lastschrift das SET NULL weg (evtl. anders implementiert).
• Danach wurde eine leere Datenbank generiert und man konnte die Views öffnen.

Dann habe ich eine bestehende v1 DB per Skript migriert:

• Die Datenbank wird geöffnet aber der Navigationsbaum zeigt sich nicht. Es kommt zu einer Exception beim Aufbau. Beim anschauen der DB habe ich gesehen, dass die DB Attribute in der Tabelle Einstellung (und auch anderswo) für die Java Boolean Attribute in der migrierten DB den Typ TINYINT haben (so wie er auch in der v1 aktuell ist) aber in der neu erzeugten DB ein BOOLEAN. Scheinbar braucht man den BOOLEAN Typ in der neuen Version. Warum aktuell einige Attribute bei Java Boolean ein TINYINT in der DB haben weiss ich nicht, BOOLEAN wäre aber wohl richtiger. Teilweise wird ja auch BOOLEAN verwendet.

Für mich zeigen sich jetzt einige Fragen die zu klären sind wenn wir wirklich umsteigen wollen:

1. Umstieg nur für JVerein oder auch Hibiscus
2. Untersuchen welche Änderungen im Code nötig sind damit wieder alles läuft
3. Welchen Weg haben wir für die Anwender um die Migration durchzuführen

• Upgrade per Script durch den Anwender
• Upgrade mit dem Migration Tool durch den Anwender
• Weg über Export(aus alter Version)/Import(in neue Version. Ich habe versucht ein Diagnose Backup zu machen und wieder einzuspielen. Das geht aber momentan nicht da es zu Fehlermeldungen kommt (referentielle Integrität verletzt). Da muss man wohl entweder den Check ausschalten oder die Reihenfolge der Tabellen ändern.
• Automatische Migration in JVerein/Hibiskus. Also irgendwie die Migration im Code machen durch Aufruf der entsprechenden Methoden die auch das Script macht. Das müsste vor dem ersten Zugriff auf die DB passieren. Ich weiss nicht ob man sowas machen kann.

Bei den ersten drei Alternativen stellt sich auch die Frage wie die User informiert werden. Ein automatischen Update sollte da wohl nicht passieren.
Die automatische Migration wäre natürlich das beste für die Anwender.

Ich freue mich auf weitere Anregungen zu diesem Thema.

[JohannMaierhofer]

PS: Ähnliche Probleme gab es wohl auch schon früher. Siehe

https://jverein-forum.de/viewtopic.php?p=17622#p17622

[tolot27]

Wie "vorwärtskompatibel" ist die 1.4.199?

• Wird SET DATA TYPE schon akzeptiert?
• Kann man BIGINT auch ohne Größe (19) definieren?
• Das TINYINT/BOOLEAN-Problem sollte IMHO transparent umsetzbar sein.
• Bei "lastschrift das SET NULL weg" lässt sich ja vermutlich auch jetzt schon anders implementieren. Nur warum muss es weg? Ist es Teil eines foreign key constraints?

Ich habe jetzt einfach mal drauf los geschrieben, ohne dass ich mich mit dem Code schon intensiv auseinandergesetzt hätte. Das kommt erst, wenn ich vollständig nach JVerein migriert bin.

[JohannMaierhofer]

Nachdem wir jetzt schon wieder ein Problem bei der Migration mit der H2DB v.1.4.199 haben, siehe #660, genauso wie das letzte mal nach 2.8.22, sollten wir und wirklich dringend überlegen wie wir da weiter machen. Entweder nehmen wir die v.1.4.196 rein oder wir steigen doch auf eine aktuelle Version um, zumindest in JVerein.

Das Problem ist halt die fehlende Migration.

Ich könnte mir einen möglichen Weg so vorstellen.

• Wir machen die 3.1.0 mit noch ausstehenden Features
• Wir machen auch die Umbenennung von Klassen wie z.B. Adresstyp und Mitgliedskonto und den Methoden
• Für eine 4.0.0 erstellen wir einen Init Code welcher eine neue leere Datenbank erzeugt. Darin nennen wir auch die Tabellen um und benennen die foreign Keys wie vorgeschlagen. Wir können dann auch alle bestehen Upgrade Dateien löschen. Es müssen halt auch alle MySQL und MariaDB User eine neue DB erzeugen
• Für die 4.0.0 ändern wir auch den Code für die Queries auf die neuen Namen, evtl. dann auch gleich als Konstanten, dann haben wir es beim nächsten mal leichter
• Und wir passen natürlich den DB Code an so dass er zur neuen Version passt

Der Umstieg würde dann so ausschauen:

• Mit der 3.1.0 macht der User einen Diagnose-Backup-Export
• Dann startet er die 4.0.0 welche eine leere Datenbank erzeugt. Die heißt auch gleich anders z.B openjverein.mv.db. Damit bleibt die alte erhalten und man könnte auch zurück zu ihr
• Dann macht er einen Diagnose-Backup-Import

Was haltet ihr davon?

Wenn wir das machen, könnten wir uns die Arbeit etwas aufteilen und z.B. parallel schon den 4.0.0 Branch zum testen erstellen.

[lenilsas]

Das finde ich klingt insgesamt ganz gut.
Ich habe vor einiger Zeit bei SynTAX die Umstellung von McKoi zu H2 umgesetzt. Da habe ich es so gemacht, dass beim start eine Box ist die den Benutzer auffordert die Datenbank umzustellen (So wie jetzt die "neue Version Box"), mit einem klick wird das automatisch ausgeführt. Dadurch ist es dem Benutzer bewusst, dass es eine Veränderung gibt. Am besten wäre es dabei so, dass es auch noch mit der alten DB laufen würde falls es zu Fehlern beim Umstieg kommt. Das ist allerdings schwierig, wenn wir die DBSpalten etc. umbenennen.
Auf jeden Fall denke ich, dass man die alte DB einfach unangetastet liegenlassen kann und wie du vorgeschlagen hast einen neue openjverein.mv.db erstellt.
Das anlegen einer neuen DB für MySQL und MariaDB Nutzer finde ich hingegen sehr ungünstig. Da wäre ich für ein Migrationsscript.

[dippeal]

Anlegen einer neuen MySQL/MariaDB finde ich unproblematisch, da die Anwender das ja schon mal gemacht habe. Ich z.B. für Hibiscus und OJV. Auch ein mysql dump wäre eine gängige Lösung. Eine Backups&Restore Anleitung/Hinweis für die OJV 4.0 (oder im Allgemeinen) halte ich für Sinnvoll.

[JohannMaierhofer]

Kann mir einer sagen ob es möglich ist die neu H2DB version nur in JVerein zu verwenden oder muss man die dann in Jameica austauschen?
Ich probiere gerade die neueste H2Db Version unter JVerein in das lib Verzeichnis zu legen und in den .classpath zu tun. Es scheint aber trotzdem die aus Jameica verwendet zu werden.
Wie müsste ich das machen um die neue Version nur bei JVerein zu verwenden?

[JohannMaierhofer]

Nach den Fixes für Diagnose Export und Import habe ich es geschafft die neueste Version h2-2.3.232 zu verwenden.
Die einzige Änderung war in AbstractDDLUpdate Zeile 245 bei BIGINT die Klammer weg zunehmen.
Ich habe dann eine leere Datenbank erzeugt und den exportierten Diagnose Backup importiert. Scheint soweit zu gehen.

Die Datentypen in der DB schauen etwas anders aus. Integer war früher Länge 10 und BIGINT Länge 19, jetzt sind es 32 und 64. Die TINYINT sind jetzt BOOLEAN, VARCHAR ist jetzt CHARACTER VARYING

Offen wäre jetzt noch:

• Ich habe die DB Library in das Jameica lib Verzeichnis gelegt. Da geht natürlich dann Hibiscus nicht mehr. Wie man das nur für JVerein machen kann weiß ich nicht und ob das überhaupt geht zwei verschiedene Versionen zu laden
• Das ander wäre dann statt alle Migrationen zu durchlaufen ein einziges File zur Intitialisierung zu erstellen.

[JohannMaierhofer]

@willuhn, hallo Olaf,
wie oben beschrieben haben wir etliche Probleme mit der H2db (zumindest mit der Version 199, 196 scheint diese Probleme nicht so zu haben, ob es da dann andere gibt weiß ich nicht) und darum war meine Überlegung ob wir nicht auf eine aktuelle Version umsteigen sollten.
Da es keine Migration dafür gibt war unsere Idee eine leere DB zu erzeugen und dann einen Diagnose Export der mit der bestehenden SW gemacht wurde zu importieren.
Wie beschrieben klappt das soweit.

Wo ich mich aber nicht auskenne ist, ob es möglich ist die neue Version nur bei JVerein zu verwenden und Hibiscus bleibt bei der alten Version, oder müsste dann auch Hibiscus umstellen?

Und wenn Hibiscus auch umsteigen müsste, wäre das überhaupt aus deiner Sicht etwas was du unterstützen würdest.

[JohannMaierhofer]

Vielleicht kann man da etwas Code abschauen.

https://github.com/manticore-projects/H2MigrationTool

[JohannMaierhofer]

Vielleicht kann man da etwas Code abschauen.

https://github.com/manticore-projects/H2MigrationTool

Ich konnte mit dem Tool die Jverein Datenbank konvertieren. Man kann sie aber nicht nutzen weil die neue DB Version die TINYINT nicht mehr nach BOOLEAN konvertiert. Die müssten wir vorher in BOOLEAN umwandeln.

[JohannMaierhofer]

Hinzu kommen ja auch noch Inkompatibilitäten in der SQL-Syntax. Auf der H2-Webseite unter https://h2database.com/html/migration-to-v2.html wird ja empfohlen, für die Migration mit dem SCRIPT-Kommando einen SQL-Dump zu erzeugen und diesen dann mit der neuen Version per RUNSCRIPT zu importieren. Das funktioniert aber oft nicht (habe ich bei Hibiscus schon getestet), weil sich das SQL-Script mit der neuen H2-Version aufgrund SQL-Syntaxänderungen nicht mehr importieren lässt.

@willuhn Hallo Olaf,
ich habe es geschafft die JVerein DB zu konvertieren. Dazu habe ich das H2MigrationTool verwendet. Ich musste allerdings zwei Dinge machen:

• Aus Alttagen gab es in der JVerein DB noch TINYINT(3) für BOOELAN Attribute. Diese werden aktuell nach Boolean gemappt, aber die neue H2DB macht das nicht mehr. Ich habe also vorher in einer Migration diese Typen in der DB nach BOOLEAN konvertiert
• Dann musste ich die Checkbox "Convert BINARY to VARBINARY" im H2MigrationTool anklicken weil sonst BLOBS zu groß gewesen wären und es zu einer Fehlermeldung kam
• PS: Die Option MODE=Oracle die default mäßig in den "Con. Param." stand musste ich löschen

Danach konnte ich die DB in JVerein öffnen und arbeiten. Die genutzte DB Version war die 2.3.232.

[willuhn]

Danke für die Tests. Dieses Vorgehen können wir den Benutzern aber nicht zumuten. Die meisten werden das nicht hinkriegen. Ich werde die nächsten Tage bei Github mal einen Fork der 1.4.199er Version machen, in der ich dann das Package und den Identifier in der JDBC-URL umbenenne. Damit kann die Version dann parallel zur neuen Version 2.x im Classpath von Jameica enthalten sein. Basierend darauf kann man dann ein integriertes Migrationstool bauen, welches dann später automatisch die Datenbanken der Plugins migrieren kann.

[JohannMaierhofer]

Das Migration Tool schafft es ja die Datenbanken zu konvertieren. Ich dachte evtl. könnten wir den Code des Tools integrieren und das dann automatisch machen.
Aber vielleicht ist dein Weg einfacher zu implementieren.

[JohannMaierhofer]

Mit der 1.4.200 tritt das Problem bei der Migration von 2.8.21 nach 2.8.22 auch auf.
Was ich aber festgestellt habe, wenn ich eine Migration von 2.8.21 auf 3.0.2 durchführe ist kein Problem da. Es werden a aber weitere Spalten bei Konto hinzugefügt.
Wenn ich aber die korrupte Db dann von 2.0.22 auf 3.0.2 migriere bleibt der Fehrer erhalten.

[willuhn]

Ich hab mir den Quellcode des Tools schon angeschaut. Es lädt die H2-Versionen jeweils in isolierten Classloadern. Das ist in Jameica in der Form nicht umsetzbar.

[willuhn]

Ich habe unter https://github.com/willuhn/h2database einen Fork der H2-Datenbank erstellt. Dort drin findet sich ein Branch 1.4.199, in dem ich das Package "org.h2" umbenannt habe in "org.h14199". Mit diesem Branch habe ich eine "h2-1.4.199-fork.jar" erzeugt. In Jameica (ab morgen im Nightly-Build) gibt es jetzt im Ordner "lib/h2" die folgende Struktur:

migration-h2/enabled/h2-1.4.199-fork.jar (mein Fork von 1.4.199 mit umbenanntem Package)
migration-h2/enabled/h2-2.3.232.jar (Aktuelles H2-Release)
migration-h2/disabled/h2-1.4.199.jar (das bisherige offizielle 1.4.199 Release

Mit dem Parameter

migration-h2=true/false

(Default=false) in .jameica/cfg/de.willuhn.jameica.system.Config.properties kann konfiguriert werden, ob entweder wie gehabt die "h2-1.4.199.jar" geladen wird oder h2-2.3.232.jar+h2-1.4.199-fork.jar

Für den Moment müsst ihr nichts in JVerein tun. Dennoch hat man in Jameica im Nightly-Build ab morgen die Option, den neuen Treiber zu laden.

Achtung! Das Aktivieren von "migration-h2=true" wirkt sich auf alle Plugins in der Jameica-Instanz aus - also ggf. auch andere Plugins, die H2 verwenden, die Migration aber noch nicht berücksichtigen.

Sobald das aktiviert ist, findet sich der alte H2-Treiber 1.4.199 nicht mehr in der Klasse "org.h2.Driver" sondern "org.h14199.Driver". Wenn man "org.h2.Driver" lädt, wird dann die neue Version 2.3.232 geladen. Damit es dann nicht zu Fehlern kommt, weil versucht werden würde, eine alte Datenbank mit dem neuen Treiber zu laden, habe ich die DBSupport-Klasse für H2 in Hibiscus mit diesem Commit willuhn/hibiscus@e67f817 angepasst. Im Wesentlichen macht das folgendes:

• Die Funktion "getJdbcDriver()" liefert nicht mehr pauschal "org.h2.Driver" sondern prüft ein internes Setting (boolean getH2Migration())
• Wenn das "true" liefert, geht das System davon aus, dass die Datenbank bereits migriert wurde und es wird "org.h2.Driver" verwendet
• Ist der Paremeter "false" (derzeit noch der Default-Wert), wird "org.h14199.Driver" verwendet.

Effekt:

• auf älteren Jameica-Versionen ist ja nach wie vor ohnehin nur der alte Treiber vorhanden und nichts muss berücksichtigt werden
• auf neueren Jameica-Versionen kann optional der Parameter "migration-h2=true" gesetzt werden
  • false (Default): unverändertes Verhalten wie bei älteren Jameica-Versionen
  • true: Plugin muss aufpassen und statt "org.h2.Driver" nun "org.h14199.Driver" als Treiber angeben

Die nächsten Schritte wären dann:

• in Jameica die Benutzeroberfläche für ein Migrationstool implementieren, das von den Plugins verwendet werden kann
• sobald das fertig ist, würde ich die Migration exemplarisch in Hibiscus umsetzen. Das kann dann von anderen Plugins als Vorlage verwendet werden.
• Sicherstellen, dass alle Plugins (die eine H2-Datenbank verwenden) entsprechenden Migrationscode mit Umschaltung org.h14199.Driver/org.h2.Driver enthalten und als Release verfügbar sind
• Ein neues Jameica-Release ausrollen, welches "migration-h2" auf "true" setzt
• Sobald die ersten User diese neue Jameica-Version verwenden, werden bei denen dann die Migrationsassistenten auf der Startseite erscheinen (die halt noch zu implementieren sind).

Zusammenfassung: Das bis jetzt umgesetzten genannten Änderungen sind erstmal nur die Grundlage, damit innerhalb einer Instanz sowohl der alte als auch der neue H2-Treiber parallel geladen sein kann und damit eine sanfte Migration grundsätzlich möglich wird, bei der der User nichts weiter berücksichtigen muss sondern irgendwann nur einen "Jetzt migrieren"-Button drücken muss.

[willuhn]

Jepp, genauso. Man könnte die Umbenennungen natürlich auch nach der Migration machen. Aber schöner ist vermutlich, wenn das vorher schon erledigt ist.

Ich gebe Bescheid, sobald in Jameica ein entsprechender Migrationsassistent existiert. Ich plane den so, dass Schema und Daten getrennt behandelt werden. Das Migrationstool unter https://github.com/manticore-projects/H2MigrationTool exportiert ja das Schema und die Insert-Statements in einer SQL-Datei und importiert das dann direkt wieder. Durch die Änderungen in der SQL-Syntax von H2 kann die SQL-Datei ja bei JVerein (bei Hibiscus genauso) nicht 1:1 wieder importiert werden, da hierbei die neue H2-Version Fehler meldet. Ich würde das Migrationstool daher so schreiben, dass es nur den Datenbank-Inhalt (also die INSERT-Statements) als SQL-Script exportiert. Ablauf dann also etwa wie folgt:

1. User startet Migration. Migrationstool erzeugt eine SQL-Datei mit den INSERT-Statements und speichert sie im Ordner der Datenbank mit ab
2. Plugin liefert den Dateinamen eines SQL-Create-Scripts mit der neuen Syntax und ggf. geänderten Spaltentypen.
3. Migrationstool erstellt mit dem Script eine neue Datenbank neben der vorhandenen
4. Migrationstool lädt das SQL-Script mit den INSERT-Statements in die neue Datenbank
5. Plugin schaltet in der JDBC-URL auf den neuen Datenbanknamen um

Neuer Datenbank-Name, damit notfalls ein Rollback möglich ist, da die alte 1.4.199er Datenbank unverändert liegen bleibt.

[JohannMaierhofer]

Ich denke wir müssen die Umbenennungen vorher machen bzw. unabhängig davon ob migriert wird oder nicht. Wir wissen ja nicht wann der User migriert bzw. migrieren kann. Er ist ja auch von anderen Plugins abhängig.

Wir werden also trotz Migrationscode weiter entwickeln müssen und sogar neue Versionen herausgeben müssen, wobei es dann Nutzer mit der alten und andere mit der neuen DB Version gibt.

Wenn wir dann dazu wieder Upgrades schreiben, wollen wir ja nicht zwischen noch nicht migrierter und migrierter DB bei den Tabellen Namen unterscheiden.

Es muss aber natürlich die zum Treiber passende Syntax verwendet werden.

[JohannMaierhofer]

Eine Frage wäre noch, wie das geht wenn der User neu mit JVerein startet. Dann müssten wir feststellen können ob das System schon migriert wurde.

Dann müssen wir ja gleich eine neue DB nach neuem Schema erzeugen und brauchen nichts zu exportieren und keine Daten importieren. Es wird dann ja auch nie mehr der Migrationsassistent angeworfen.

[willuhn]

Ich denke wir müssen die Umbenennungen vorher machen bzw. unabhängig davon ob migriert wird oder nicht. Wir wissen ja nicht wann der User migriert bzw. migrieren kann. Er ist ja auch von anderen Plugins abhängig.
[...]
Wenn wir dann dazu wieder Upgrades schreiben, wollen wir ja nicht zwischen noch nicht migrierter und migrierter DB bei den Tabellen Namen unterscheiden.

Ja, da ist natürlich in der Tat sinnvoller, die Umbennnungen vorher zu machen.

[willuhn]

Eine Frage wäre noch, wie das geht wenn der User neu mit JVerein startet. Dann müssten wir feststellen können ob das System schon migriert wurde.

In Hibiscus plane ich das so, dass ich irgendwann prüfe, ob in Jameica bereits die neue H2-Version verwendet. Wenn ja, lege ich bei Neuinstallationen direkt die neue Datenbank an. Ich gebe Bescheid, sobald das in Hibiscus implementiert ist. Wird aber sicher noch einige Zeit dauern.