Hibernate-reactive: hibernate.jdbc.time_zone no compatible con las columnas TIME

En teoría ya debería funcionar :-)
https://github.com/hibernate/hibernate-reactive/issues/667

Echaré un vistazo

¿Puedes pasar un ejemplo de una entidad que estás usando? Un reproductor sería aún mejor. Puede usar JBang para iniciar un caso de prueba de ejemplo:

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

Puede reemplazar idea con su IDE favorito

No importa... Puedo ver la excepción

para más detalles, estamos usando LocalTime en la Entidad y TIME en la base de datos

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

Mesa
CREATE TABLE IF NOT EXISTS A ( time TIME )

Entonces, el problema aquí es que la noción de un _tiempo_ dividido en zonas está completamente rota y nunca debería haberse introducido en SQL (afortunadamente, la mayoría de las bases de datos no lo admiten). La asignación entre zonas horarias _depende de la fecha_, por lo que solo tienen sentido las fechas y horas divididas en zonas.

Hasta este momento no tenía idea del comportamiento de hibernate.jdbc.time_zone , lo cual me parece bastante malo a primera vista, y tal vez deberíamos cambiarlo en H6.

Así que no estoy seguro de qué hacer aquí. ¿"Arreglarlo" para que haga lo mismo que ORM, o simplemente ignorar la configuración cuando se trabaja con tiempos?

¿O simplemente ignorar la propiedad por completo y descubrir cómo hacer esto usando una propiedad de conexión en su lugar? (Es posible que necesite una nueva función en el cliente Vert.x, no estoy seguro).

Estoy quitando la etiqueta de "error". No es un error que los tiempos divididos en zonas no funcionen. Están rotos por _design_.

(Por supuesto, esto es en parte mi culpa por no profundizar más cuando hice #676 y notar el problema con el comportamiento de hibernate.jdbc.time_zone ).

Empecé una discusión aquí .

La asignación entre zonas horarias _depende de la fecha_, por lo que solo tienen sentido las fechas y horas divididas en zonas.

Ok, pero están tratando de almacenar un LocalTime que no tiene ninguna zona horaria adjunta y no debería requerir ninguna conversión.
¿Me estoy perdiendo de algo?

Pero eso no es lo que hace esta propiedad, al parecer. En ORM, adjunta una zona horaria a la cosa.

Al menos, me parece. (Nunca he podido entender completamente la semántica de ese método JDBC).

"Arréglalo" para que haga lo mismo que ORM

Creo que comprobaré qué hace ORM y haré lo mismo. Probablemente sea el comportamiento que los usuarios que están familiarizados con ORM esperarán de todos modos.

Creo que comprobaré qué hace ORM y haré lo mismo.

jajajaja oh dulce niño de verano!

ORM llama a un método JDBC que tiene una semántica esencialmente no documentada.

(Y probablemente se comporte de manera diferente en cada base de datos).

Entonces, para recapitular parte de la discusión con @yrodiere sobre Zulip:

1. Él dice que todo esto es muy frágil (y probablemente roto) en ORM para empezar, en parte porque todos los controladores JDBC hacen cosas frágiles y diferentes.
2. Lo que decidí hacer para manejar Timestamp s con hibernate.jdbc.time_zone (que intenta convertir el Timestamp dado a la zona horaria dada antes de pasarlo al cliente Vert.x SQL) podría o puede que no sea robusto, pero ciertamente no parece conceptualmente correcto para Time .

Entonces, las opciones son (1) simplemente ignorar la configuración en silencio, (2) explotar cuando la configuración está presente o (3) hacer algo que sabemos que no funciona.

Me inclino por ir con (2).

_Supongo_ que podríamos seguir haciendo lo que estamos haciendo actualmente para las fechas y horas, y simplemente ignorar la configuración que se refiere a las horas. Pero vaya, eso equivale a presentar una interpretación nueva y diferente de una característica que ya está un poco rota. Brrr

@pqab ¿por qué precisamente usa esta configuración? ¿Podría razonablemente simplemente _no_ usarlo?

@pqab ¿por qué _precisamente_ usa esta configuración? ¿Podría razonablemente simplemente _no_usarlo?

Y la misma pregunta para @Ngosti2000

Para ser justos, no esperaba que se aplicara a objetos que no tienen zona horaria como LocalTime .

Sospecho que el problema es que es una propiedad global y si la configura porque tiene sentido en otros casos, no creo que haya una forma de deshabilitarla para campos específicos. ¿O tal vez lo hay?

Para ser justos, no esperaba que se aplicara a objetos que no tienen zona horaria como LocalTime .

Correcto, igual. Asumimos demasiada cordura.

No creo que haya una forma de desactivarlo para campos específicos. ¿O tal vez lo hay?

No que yo sepa.

tenemos otros campos DATE que necesitan la propiedad global, pero esperábamos que el campo TIME se ignorara porque no tiene zona horaria

Hecho