Hibernate-reactive: hibernate.jdbc.time_zone não suportado em colunas TIME

Em teoria, já deve funcionar :-)
https://github.com/hibernate/hibernate-reactive/issues/667

vou dar uma olhada

Você pode passar um exemplo de uma entidade que você está usando? Um reprodutor seria ainda melhor. Você pode usar o JBang para iniciar um caso de teste de exemplo:

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

Você pode substituir idea pelo seu IDE favorito

Deixa pra lá... eu posso ver a exceção

para mais detalhes, estamos usando LocalTime na Entidade e TIME no banco de dados

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

Mesa
CREATE TABLE IF NOT EXISTS A ( time TIME )

Portanto, o problema aqui é que a noção de _time_ zoneado está totalmente quebrada e nunca deveria ter sido introduzida no SQL (felizmente, a maioria dos bancos de dados não a suporta). O mapeamento entre os fusos horários _depende da data_ e, portanto, apenas os datetimes zoneados fazem sentido.

Até este momento eu não tinha idéia sobre o comportamento de hibernate.jdbc.time_zone , que me parece muito ruim, à primeira vista, e talvez devêssemos mudá-lo em H6.

Então não tenho certeza do que fazer aqui. "Corrigir" para fazer a mesma coisa ruim que o ORM, ou simplesmente ignorar a configuração ao trabalhar com tempos?

Ou simplesmente ignore a propriedade e descubra como fazer isso usando uma propriedade de conexão? (Pode precisar de um novo recurso no cliente Vert.x, não tenho certeza.)

Estou removendo o rótulo "bug". Não é um bug que os tempos de zona não funcionem. Eles são quebrados por _design_.

(É claro que isso é parcialmente minha culpa por não cavar mais fundo quando fiz #676 e perceber o problema com o comportamento de hibernate.jdbc.time_zone .)

Eu comecei uma discussão aqui .

O mapeamento entre os fusos horários _depende da data_ e, portanto, apenas os datetimes zoneados fazem sentido.

Ok, mas eles estão tentando armazenar um LocalTime que não possui nenhum fuso horário anexado e não deve exigir nenhuma conversão.
Estou esquecendo de algo?

Mas não é isso que esta propriedade faz, ao que parece. No ORM, ele anexa um fuso horário à coisa.

Pelo menos, parece-me. (Eu nunca fui capaz de entender completamente a semântica desse método JDBC.)

"Corrigir" para fazer a mesma coisa ruim que o ORM

Acho que vou verificar o que o ORM faz e fazer o mesmo. É provavelmente o comportamento que os usuários que estão familiarizados com ORM esperarão de qualquer maneira.

Acho que vou verificar o que o ORM faz e fazer o mesmo.

hahahaha oh doce criança de verão!

O ORM chama um método JDBC que tem uma semântica essencialmente não documentada.

(E provavelmente se comporta de maneira diferente em cada banco de dados.)

Então, para recapitular parte da discussão com @yrodiere no Zulip:

1. Ele diz que tudo isso é muito frágil (e provavelmente quebrado) no ORM para começar, em parte porque todos os drivers JDBC fazem coisas frágeis e diferentes.
2. O que eu decidi fazer para lidar com Timestamp s com hibernate.jdbc.time_zone (que tenta converter o Timestamp fornecido para o fuso horário fornecido antes de passá-lo para o cliente SQL Vert.x) pode ou pode não ser robusto, mas certamente não parece conceitualmente correto para um Time .

Portanto, as opções são (1) ignorar silenciosamente a configuração, (2) explodir quando a configuração estiver presente ou (3) fazer algo que sabemos que está quebrado.

Estou inclinado a ir com (2).

Eu _suponho_ que poderíamos continuar fazendo o que estamos fazendo atualmente para datetimes, e simplesmente ignorar a configuração que se trata de times. Mas caramba, isso equivale a introduzir uma interpretação nova e diferente de um recurso que já está meio quebrado. Brrr.

@pqab por que exatamente você usa essa configuração? Você poderia razoavelmente, tipo, apenas _não_ usá-lo?

@pqab por que _precisamente_ você usa essa configuração? Você poderia razoavelmente, tipo, apenas _não_usar?

E a mesma pergunta para @Ngosti2000

Para ser justo, eu não esperava que fosse aplicado a objetos que não possuem fuso horário como LocalTime .

Suspeito que o problema seja que seja uma propriedade global e se você a definir porque faz sentido em outros casos, não acho que haja uma maneira de desativá-la para campos específicos. Ou talvez haja?

Para ser justo, eu não esperava que fosse aplicado a objetos que não possuem fuso horário como LocalTime .

Certo, o mesmo. Assumimos muita sanidade.

Eu não acho que haja uma maneira de desativá-lo para campos específicos. Ou talvez haja?

Não que eu saiba.

temos alguns outros campos DATE que precisam da propriedade global, mas esperávamos que o campo TIME fosse ignorado porque não tem fuso horário

Feito