Probleme mit Diagnose Backup Import von Buchungen

[JohannMaierhofer]

In #672 gibt es Probleme beim Diagnose Backup Import von Buchungen.

Die Fehlermeldung ist:
"1 fehlerhaft class java.lang.Integer cannot be cast to class java.lang.Long (java.lang.Integer and java.lang.Long are in module java.base of loader 'bootstrap'), überspringe"

Das passiert wenn eine Spendenbescheinigung referenziert ist und dann im plausi Check in Zeile 174 aufgerufen wird mit getBuchungsart().

Wenn man den Teil im Plausi auskommentiert kann man die Buchungen importieren.

Was mir aufgefallen ist, ist, dass im Diagnose Backup XML auch alle Long Attribute als Integer exportiert sind, auch die Buchungsart.
@willuhn Kann es sein, dass im Plausi das dann noch nicht korrekt funktioniert.

[JohannMaierhofer]

Jetzt habe ich die Lösung gefunden. In der Methode getBuchungsart() muss man Long durch Object ersetzen.
So etwas haben wir aber noch öfters im Code.

[willuhn]

Das Format, in dem das in der XML-Datei exportiert wird (also ob es als Integer oder Long exportiert wird), wird nicht von Jameica vorgegeben sondern so, wie es der JDBC-Treiber der Datenbank über die JDBC-Meta-Daten gemeldet hat. Wenn ich den Code richtig verstehe, ist die Spalte "buchungsart" in der Datenbank als BIGINT definiert. Da könnte es schon sein, dass der JDBC-Treiber das als Integer statt Long liefert (wobei die Empfehlung wohl ist, dass der JDBC-Treiber das nach Long mappen sollte). Unter Umständen ist das eine vergleichbare Problematik wie die mit den Double/BigDecimal, wo ich empfohlen hatte, den Cast stattdessen auf "Number" zu machen, da das generischer ist und anschließend ein "intValue()" oder "longValue()" je nach Bedarf.

[JohannMaierhofer]

Das interessante ist aber, dass das wärend des Diagnose Backup Import passiert. Die Methode wurde ja bereits im Normalbetrieb so wie sie war aufgerufen und da gab es keine Exception.

[tolot27]

Wenn ich den Code richtig verstehe, ist die Spalte "buchungsart" in der Datenbank als BIGINT definiert. Da könnte es schon sein, dass der JDBC-Treiber das als Integer statt Long liefert (wobei die Empfehlung wohl ist, dass der JDBC-Treiber das nach Long mappen sollte).

Ich kann mir nicht vorstellen, dass der JDBC-Treiber das mal so und mal so macht. Er wird wie im JDBC Mapping empfohlen, immer Long zurück liefern. So macht erst das zumindest bis jetzt. Sonst hätten wir noch noch Cast-Exceptions. Allerdings könnten wir bei den ganzen Umbenennungen in #662 vielleicht doch auf non-negative 32-Bit IDs (INTEGER) umsteigen. Das reicht nach meiner Ansicht völlig aus. Bevor wir 4,2 Mrd. Zeilen in irgendeiner der Tabellen haben, sind wir längst nicht mehr bzw. es wird einen standardisierten numerischen 64-Bit SQL-Typen geben, der von den meisten/allen DB-Systemen unterstützt wird.
Wenn wir das machen, wären wir Standardkonform, hätten deutlich kompaktere und performantere Indices und keine Probleme auf der Java-Seite, außer dass es in Java keine non-negativen Integer gibt.

[JohannMaierhofer]

Mich wundert ja sowieso etwas, dass wir BIGINT mit Länge 19 erzeugen und die INT mit Länge 10.
Wenn ich mir die neuere Version von H2db anschaue, kann man da die 19 gar nicht mehr angeben. Dort hat ein Integer schon Länge 32 und der BIGINT hat 64.
Wenn unser BIGINT nur 19 lang ist, dann ist das ja noch weniger als 32 und darum noch kürzer als ein Integer. Warum wird das dann als BIGINT definiert? Und was passiert eigentlich wenn unsere Integer länger als 10 werden bzw. die Long länger als 19?

Jedenfalls steht in unseren Diagnose Backup bei den BIGINT ein Integer im XML.

Ich probiere morgen mal einen Export aus der neuen Datenbank. Mal schauen ob da auch Integer steht.

PS: Wir haben wohl aus Altlasten auch noch einige Boolean als TINYINT(5) in der DB. Bei der unserer alten DB Version wird das wohl noch zu Boolean gemapped. Bei der aktuellen H2DB Version klappt das nicht mehr.
Wir sollten die nach boolean migrieren.

[JohannMaierhofer]

Allerdings könnten wir bei den ganzen Umbenennungen in #662 vielleicht doch auf non-negative 32-Bit IDs (INTEGER) umsteigen

Ich habe gesehen, dass im Code und der DB auch die -1 vorkommt. Die ist negativ.

[tolot27]

Mich wundert ja sowieso etwas, dass wir BIGINT mit Länge 19 erzeugen und die INT mit Länge 10.
Wenn ich mir die neuere Version von H2db anschaue, kann man da die 19 gar nicht mehr angeben. Dort hat ein Integer schon Länge 32 und der BIGINT hat 64.
Wenn unser BIGINT nur 19 lang ist, dann ist das ja noch weniger als 32 und darum noch kürzer als ein Integer. Warum wird das dann als BIGINT definiert? Und was passiert eigentlich wenn unsere Integer länger als 10 werden bzw. die Long länger als 19?

Hier ist MySQL etwas lazy mit der Definition. Nur bei BIT(M) gibt die Zahl in Klammern (M) die Anzahl der Bits an, die gespeichert werden. Bei den anderen nummerischen Typen ist es die Anzahl an Dezimalstellen im String. Beispiel: INT(11) kann die minimale Zahl von -2147483647 erfassen, was einer Stringlänge von 11 entspricht. Gespeichert wird jedoch immer ein 32-Bit-Wert, egal ob man INT(8) bei der Spaltendefinition angibt oder den Wert 42 speichert.
So ist es auch mit BIGINT. Das ist immer ein 64-Bit-Wert. Relevant sind die Zahlen M und D nur für den Datentyp DECIMAL.

[tolot27]

Allerdings könnten wir bei den ganzen Umbenennungen in #662 vielleicht doch auf non-negative 32-Bit IDs (INTEGER) umsteigen

Ich habe gesehen, dass im Code und der DB auch die -1 vorkommt. Die ist negativ.

Gut, dann signed INTEGER. Das ändert meine ursprüngliche Aussage bzgl. der Nutzungsdauer jedoch nicht signifikant. 😄

[JohannMaierhofer]

Mich wundert ja sowieso etwas, dass wir BIGINT mit Länge 19 erzeugen und die INT mit Länge 10.
Wenn ich mir die neuere Version von H2db anschaue, kann man da die 19 gar nicht mehr angeben. Dort hat ein Integer schon Länge 32 und der BIGINT hat 64.
Wenn unser BIGINT nur 19 lang ist, dann ist das ja noch weniger als 32 und darum noch kürzer als ein Integer. Warum wird das dann als BIGINT definiert? Und was passiert eigentlich wenn unsere Integer länger als 10 werden bzw. die Long länger als 19?

Hier ist MySQL etwas lazy mit der Definition. Nur bei BIT(M) gibt die Zahl in Klammern (M) die Anzahl der Bits an, die gespeichert werden. Bei den anderen nummerischen Typen ist es die Anzahl an Dezimalstellen im String. Beispiel: INT(11) kann die minimale Zahl von -2147483647 erfassen, was einer Stringlänge von 11 entspricht. Gespeichert wird jedoch immer ein 32-Bit-Wert, egal ob man INT(8) bei der Spaltendefinition angibt oder den Wert 42 speichert. So ist es auch mit BIGINT. Das ist immer ein 64-Bit-Wert. Relevant sind die Zahlen M und D nur für den Datentyp DECIMAL.

Ich dachte mir da dann auch schon. Da hat wohl die H2DB die Syntax geändert. Wenn ich in eine unserer aktuellen DB schaue steht da eben die 10 und 19. Wenn ich unsere DB mit der neuesten Version (2.3.232) der DB erzeuge steht dann 32 und 64 bei den Spalten.