Hibernate-reactive: hibernate.jdbc.time_zone non pris en charge sur les colonnes TIME

En théorie, cela devrait déjà fonctionner :-)
https://github.com/hibernate/hibernate-reactive/issues/667

J'irais regarder

Pouvez-vous passé un exemple d'une entité que vous utilisez? Un reproducteur serait encore mieux. Vous pouvez utiliser JBang pour démarrer un exemple de cas de test :

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

Vous pouvez remplacer idea par votre IDE préféré

Peu importe .... Je peux voir l'exception

pour plus de détails, nous utilisons LocalTime dans l'entité et TIME dans la base de données

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

Table
CREATE TABLE IF NOT EXISTS A ( time TIME )

Le problème ici est donc que la notion de _time_ zoné est entièrement cassée et n'aurait jamais dû être introduite dans SQL (heureusement, la plupart des bases de données ne le supportent pas). Le mappage entre les fuseaux horaires _dépend de la date_, et donc seules les dates/heures zonées ont un sens.

Jusqu'à ce moment, je n'avais aucune idée du comportement de hibernate.jdbc.time_zone , qui me semble plutôt mauvais, à première vue, et peut-être devrions-nous le changer dans H6.

Donc je ne sais pas quoi faire ici. "Corrigez-le" pour qu'il fasse la même mauvaise chose que ORM, ou ignorez simplement le paramètre lorsque vous travaillez avec des heures ?

Ou simplement ignorer complètement la propriété et trouver comment faire cela en utilisant une propriété de connexion à la place ? (Peut avoir besoin d'une nouvelle fonctionnalité dans le client Vert.x, je ne suis pas sûr.)

Je supprime l'étiquette "bug". Ce n'est pas un bug que les horaires zonés ne fonctionnent pas. Ils sont cassés par _design_.

(C'est bien sûr en partie ma faute si je n'ai pas creusé plus profondément quand j'ai fait #676 et remarqué le problème avec le comportement de hibernate.jdbc.time_zone .)

J'ai lancé une discussion ici .

Le mappage entre les fuseaux horaires _dépend de la date_, et donc seules les dates/heures zonées ont un sens.

Ok, mais ils essaient de stocker un LocalTime qui n'a pas de fuseau horaire attaché et ne devrait pas nécessiter de conversion.
Est-ce que je manque quelque chose?

Mais ce n'est pas ce que fait cette propriété, semble-t-il. Dans ORM, il attache un fuseau horaire à la chose.

Du moins, il me semble. (Je n'ai jamais été capable de comprendre complètement la sémantique de cette méthode JDBC.)

"Corrigez-le" pour qu'il fasse la même mauvaise chose que l'ORM

Je pense que je vais vérifier ce que fait ORM et faire de même. C'est probablement le comportement auquel les utilisateurs familiers avec ORM s'attendront de toute façon.

Je pense que je vais vérifier ce que fait ORM et faire de même.

hahahaha oh doux enfant d'été!

ORM appelle une méthode JDBC qui a essentiellement une sémantique non documentée.

(Et se comporte probablement différemment sur chaque base de données.)

Alors pour récapituler une partie de la discussion avec @yrodiere sur Zulip :

1. Il dit que tout cela est très fragile (et probablement cassé) dans ORM pour commencer, en partie parce que tous les pilotes JDBC font des choses fragiles et différentes.
2. Ce que j'ai décidé de faire pour gérer Timestamp s avec hibernate.jdbc.time_zone (qui essaie de convertir le Timestamp donné dans le fuseau horaire donné avant de le transmettre au client SQL Vert.x) pourrait ou peut-être pas robuste, mais cela ne semble certainement pas conceptuellement correct pour un Time .

Ainsi, les options sont (1) ignorer silencieusement le paramètre, (2) exploser lorsque le paramètre est présent, ou (3) faire quelque chose que nous savons être cassé.

Je suis enclin à aller avec (2).

Je _suppose_ que nous pourrions continuer à faire ce que nous faisons actuellement pour les dates et heures, et ignorer simplement le paramètre auquel il s'agit. Mais bon sang, cela revient à introduire une nouvelle interprétation différente d'une fonctionnalité qui est déjà un peu cassée. Brr.

@pqab pourquoi utilisez-vous précisément ce paramètre ? Pourriez-vous raisonnablement, par exemple, ne pas l'utiliser ?

@pqab pourquoi _précisément_ utilisez-vous ce paramètre ? Pourriez-vous raisonnablement, par exemple, ne pas l'utiliser ?

Et même question pour @Ngosti2000

Pour être juste, je ne m'attendais pas à ce qu'il soit appliqué à des objets qui n'ont pas de fuseau horaire comme LocalTime .

Je soupçonne que le problème est qu'il s'agit d'une propriété globale et si vous la définissez parce que cela a du sens dans d'autres cas, je ne pense pas qu'il existe un moyen de la désactiver pour des champs spécifiques. Ou peut-être y en a-t-il ?

Pour être juste, je ne m'attendais pas à ce qu'il soit appliqué à des objets qui n'ont pas de fuseau horaire comme LocalTime .

Exact, pareil. Nous avons supposé trop de bon sens.

Je ne pense pas qu'il existe un moyen de le désactiver pour des champs spécifiques. Ou peut-être y en a-t-il ?

Pas que je sache de.

nous avons d'autres champs DATE qui ont besoin de la propriété globale, mais nous nous attendions à ce que le champ TIME soit ignoré car il n'a pas de fuseau horaire

Terminé