41 lines
5.7 KiB
Markdown
41 lines
5.7 KiB
Markdown
# 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 8df13d52d7ffeb6598ce0797f7738484cd425f88 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 d61aaf9ad4f30ba43f337fa320e7f37cb262bdab 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.
|