5.7 KiB
H2-/Liquibase-Prototyp — abgeschlossen
H2 2.4.240 im File-Modus ohne PostgreSQL-Kompatibilitätsmodus. Liquibase ist im Versionskatalog strikt auf 4.33.0 begrenzt (Apache-2.0); beide Migrationen sind formatted SQL und vorerst ausschließlich H2-spezifische Testressourcen.
Die ersten beiden Prüfungen bestehen:
- Ein separater JVM-Prozess legt die Datenbank an, migriert sie und schreibt Beispieldaten. Ein neuer JVM-Prozess liest danach Stunden und Unicode-Freitext unverändert. Erneuter Aufruf desselben Changelogs erzeugt keine weitere Migration. Unquotierte Tabellen-/Spaltennamen werden konsistent verwendet; Varianten der Groß-/Kleinschreibung sowie Liquibase-Metadaten sind geprüft.
- Nach geschlossenem Prozess wird die vollständige mv.db-Datei gesichert. Eine Upgrade-Migration ergänzt erfolgreich eine Spalte, bevor der folgende Changeset absichtlich fehlschlägt. Der Test weist die teilweise erfolgte Schemaänderung nach. Nach Schließen aller Verbindungen wird die Sicherung zurückgespielt; ein neuer Prozess prüft die Daten, anschließend werden ursprüngliches Schema und Migrationshistorie verifiziert.
Ein erster Durchlauf deckte einen fehlenden Commit im Probeprozess auf: Liquibase hinterließ die verwendete Verbindung im manuellen Commit-Modus. Der Probeprozess committet den anschließenden Schreibvorgang jetzt ausdrücklich. In der Anwendung werden Migration und Fachtransaktionen getrennte Verantwortlichkeiten erhalten.
Die ergänzte JdbcTemplate-Prüfung behandelt Eigentümerfilter, veraltete Versionsnummern und Rollback einer bereits erfolgten Änderung. Der vollständige tools/ci-jvm-Lauf besteht: fünf JVM-Tests ohne Fehler sowie die Produktions-JAR-PWA-Prüfung. Der HTTP-Test legt den Produktionsmodus ausdrücklich fest, damit er nicht vom Vaadin-Entwicklungsserver oder vorherigen Buildaufrufen abhängt.
Zusätzlich geprüft: zwei parallele erste Einträge mit je acht Stunden für denselben Nutzer und unterschiedliche Kunden. Die Sperre auf der bestehenden Nutzerzeile serialisiert die Transaktionen; genau ein Eintrag wird übernommen, der zweite wegen der Tagesgrenze abgelehnt. Exakt zwölf Stunden sind zulässig. Monatssummen schließen fremde Nutzer und angrenzende Monate aus und gruppieren nach Kunde.
Spring Data JDBC ist praktisch mit derselben Tabelle und derselben Tagesgrenzen-Transaktion geprüft: Kotlin-Mapping, eigentümerbezogener Finder, automatische Versionsfortschreibung, veraltete Speicherung und Ablehnung eines zweiten Eintrags oberhalb des Tageslimits.
Ergänzung: jOOQ als dritte Variante
jOOQ 3.21.8 (freie Apache-2.0-Ausgabe, org.jooq) erzeugt Kotlin-Tabellen und Felder aus einer temporären H2-Datei. Der Gradle-Schritt generatePrototypeJooq wendet zuerst das vorhandene Liquibase-SQL an; ein zweites manuell gepflegtes Schema ist nicht nötig. Generierte Dateien liegen ausschließlich unter build/. Der Generator läuft mit maximal 256 MiB Java-Heap; das ist keine Messung des Gesamtverbrauchs. Die eigentliche erste Generierung dauerte lokal etwa 1,7 Sekunden, ohne Dependency-Download oder Kotlin-Kompilierung.
Drei zusätzliche Tests prüfen:
- Eigentümerfilter, veraltete Versionen, Datumsverschiebungen mit Prüfung beider Tagesbestände sowie exakt zwölf und abgelehnte dreizehn Stunden.
- Typisierte Monatssummen mit Monatsgrenzen und fremden Nutzern. Ein absichtlich abgebrochener äußerer Spring-Transaktionsblock rollt die jOOQ-Einfügung zurück. Der TransactionAwareDataSourceProxy bindet jOOQ an dieselbe Spring-Verbindung.
- Zwei parallele erste Achtstundenbuchungen: genau eine wird angenommen, eine wegen der Tagesgrenze abgelehnt.
| Variante | Praktischer Nutzen | Zusätzliche Verantwortung / Aufwand |
|---|---|---|
| JdbcTemplate | Explizites SQL und einfache Build-Konfiguration | Spaltennamen und Mapping von Hand; Schemafehler erst zur Laufzeit |
| Spring Data JDBC | Kotlin-Mapping und automatische Versionsprüfung | Eigentümerprüfung bei save und Transaktion für Tagessumme weiterhin selbst implementieren |
| jOOQ | Generierte Feldtypen, explizite Eigentümer-/Versionsprädikate und typisierte Aggregate | Zusätzlicher Generierungsschritt; Eigentümerfilter, Sperren und Fachregeln weiterhin selbst implementieren |
Auswahl nach dem erweiterten Vergleich: H2 und jOOQ mit Spring-Transaktionen. Die zusätzliche Codegenerierung ist für dieses SQL-orientierte Modell vertretbar; sie reduziert manuelle Feldnamen und Mapping bei den Auswertungen. Dies ist eine Wartbarkeitsentscheidung, kein behaupteter Laufzeit- oder RAM-Vorteil. Begründung und Konsequenzen: docs/decisions/0001-h2-jdbc.md.
Lokal besteht tools/ci-jvm mit elf JVM-Tests und erfolgreicher Produktions-JAR-PWA-Prüfung. Die drei Zugriffsvarianten und ihre Abhängigkeiten bleiben vorerst im Prototyp; produktives Schema, vollständige Fachoperationen und deren Akzeptanztests folgen in den vorgesehenen Fundament-/Fachknoten. Der Vergleich ist kein GraalVM-Kompatibilitätsnachweis.
CI-Verifikation
Werkator hat Commit 8df13d52d7 am 2026-09-08 um 18:57 UTC als failed mit Dauer null Sekunden erfasst. Das archivierte build.log enthält ausschließlich den Build-Kopf, keine Compiler- oder Testausgabe. Die API antwortete kurzzeitig mit HTTP 503; anschließend war sie wieder erreichbar. SSH auf mih09.hostsharing.net wurde mit Connection refused abgewiesen. Ursache ungeklärt; dies ist kein nachgewiesener jOOQ-Testfehler. Der anschließende Build von d61aaf9ad4 bestand in 120 Sekunden: Clean-Build, Kotlin-Codegenerierung aus frisch migrierter H2-Datei, Tests und Produktions-JAR/PWA-Smoke (PASS). Das Release-Manifest verweist auf denselben Commit. Damit ist der Persistenzprototyp abgeschlossen. Die Ursache des vorherigen sofortigen Abbruchs wurde nicht nachgewiesen.