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.