Hibernate-reactive: hibernate.jdbc.time_zone wird für TIME-Spalten nicht unterstützt

Theoretisch sollte es schon funktionieren :-)
https://github.com/hibernate/hibernate-reactive/issues/667

ich werde nachsehen

Können Sie ein Beispiel für eine Entität angeben, die Sie verwenden? Ein Repro wäre noch besser. Sie können JBang verwenden, um einen Beispiel-Testfall zu starten:

jbang init -t mysql-reproducer@hibernate/hibernate-reactive Issue856.java
jbang edit --open=idea --live Issue856.java

Sie können idea durch Ihre bevorzugte IDE ersetzen

Vergiss es .... Ich kann die Ausnahme sehen

Für weitere Details verwenden wir LocalTime in der Entität und TIME in der Datenbank

Juristische Person
public class A { @Column(name = "time") private LocalTime time; }

Tisch
CREATE TABLE IF NOT EXISTS A ( time TIME )

Das Problem hier ist also, dass das Konzept einer gezonten _Zeit_ völlig kaputt ist und niemals in SQL hätte eingeführt werden dürfen (glücklicherweise unterstützen dies die meisten Datenbanken nicht). Die Zuordnung zwischen Zeitzonen _hängt vom Datum ab_, daher sind nur gezonte Datumsangaben sinnvoll.

Bis zu diesem Moment hatte ich keine Ahnung vom Verhalten von hibernate.jdbc.time_zone , das mir auf den ersten Blick ziemlich schlecht erscheint, und vielleicht sollten wir es in H6 ändern.

Ich bin mir also nicht sicher, was ich hier tun soll. "Fixieren" Sie es, um dasselbe zu tun wie ORM, oder ignorieren Sie die Einstellung einfach, wenn Sie mit Zeiten arbeiten?

Oder ignorieren Sie die Eigenschaft einfach ganz und finden Sie heraus, wie Sie dies stattdessen mit einer Verbindungseigenschaft tun können? (Möglicherweise ist eine neue Funktion im Vert.x-Client erforderlich, ich bin mir nicht sicher.)

Ich entferne das "Bug"-Label. Es ist kein Fehler, dass Zonenzeiten nicht funktionieren. Sie werden von _design_ gebrochen.

(Das ist natürlich teilweise meine Schuld, dass ich bei #676 nicht tiefer gegraben habe und das Problem mit dem Verhalten von hibernate.jdbc.time_zone bemerkt habe.)

Ich habe hier eine Diskussion gestartet.

Die Zuordnung zwischen Zeitzonen _hängt vom Datum ab_, daher sind nur gezonte Datumsangaben sinnvoll.

Ok, aber sie versuchen, ein LocalTime zu speichern, das keine Zeitzone hat und keine Konvertierung erfordern sollte.
Übersehe ich etwas?

Aber das scheint diese Eigenschaft nicht zu tun. In ORM fügt es dem Ding eine Zeitzone hinzu.

Zumindest scheint es mir. (Ich war nie in der Lage, die Semantik dieser JDBC-Methode vollständig zu verstehen.)

"Reparieren" Sie es, um dasselbe zu tun wie ORM

Ich denke, ich werde überprüfen, was ORM tut, und dasselbe tun. Es ist wahrscheinlich das Verhalten, das Benutzer, die mit ORM vertraut sind, sowieso erwarten werden.

Ich denke, ich werde überprüfen, was ORM tut, und dasselbe tun.

hahahaha oh süßes Sommerkind!

ORM ruft eine JDBC-Methode auf, die im Wesentlichen undokumentierte Semantik hat.

(Und verhält sich wahrscheinlich in jeder Datenbank anders.)

Um einen Teil der Diskussion mit @yrodiere auf Zulip noch einmal zusammenzufassen:

1. Er sagt, dass dieses Zeug in ORM zunächst sehr anfällig (und wahrscheinlich kaputt) ist, teilweise weil alle JDBC-Treiber anfällige und unterschiedliche Dinge tun.
2. Was ich entschieden habe, um Timestamp s mit hibernate.jdbc.time_zone zu handhaben (das versucht, das gegebene Timestamp in die gegebene Zeitzone zu konvertieren, bevor es an den Vert.x SQL-Client übergeben wird), könnte oder ist möglicherweise nicht robust, aber es scheint für ein Time konzeptionell nicht korrekt zu sein.

Die Optionen sind also (1) die Einstellung einfach stillschweigend ignorieren, (2) explodieren, wenn die Einstellung vorhanden ist, oder (3) etwas tun, von dem wir wissen, dass es kaputt ist.

Ich tendiere zu (2).

Ich _nehme_ an, wir könnten das tun, was wir derzeit für datetimes tun, und einfach die Einstellung ignorieren, auf die es ankommt. Aber meine Güte, das läuft darauf hinaus, eine neue und anders kaputte Interpretation eines Features einzuführen, das bereits irgendwie kaputt ist. Brrr.

@pqab warum genau verwendest du diese Einstellung? Könnten Sie es vernünftigerweise einfach _nicht_ verwenden?

@pqab warum _genau_ verwendest du diese Einstellung? Könnten Sie es vernünftigerweise einfach _nicht_verwenden?

Und dieselbe Frage für @Ngosti2000

Um fair zu sein, ich habe nicht erwartet, dass es auf Objekte angewendet wird, die keine Zeitzone wie LocalTime haben.

Ich vermute, das Problem ist, dass es sich um eine globale Eigenschaft handelt, und wenn Sie sie festlegen, weil sie in anderen Fällen sinnvoll ist, glaube ich nicht, dass es eine Möglichkeit gibt, sie für bestimmte Felder zu deaktivieren. Oder vielleicht doch?

Um fair zu sein, ich habe nicht erwartet, dass es auf Objekte angewendet wird, die keine Zeitzone wie LocalTime haben.

Richtig, gleich. Wir haben zu viel Vernunft angenommen.

Ich glaube nicht, dass es eine Möglichkeit gibt, es für bestimmte Felder zu deaktivieren. Oder vielleicht doch?

Nicht, dass ich davon Wüste.

Wir haben einige andere DATE -Felder, die die globale Eigenschaft benötigen, aber wir haben erwartet, dass das TIME -Feld ignoriert werden sollte, da es keine Zeitzone hat

Getan