Hibernate-reactive: hibernate.jdbc.time_zone не поддерживается в столбцах TIME

По идее уже должно работать :-)
https://github.com/hibernate/hibernate-reactive/issues/667

я взгляну

Можете ли вы пропустить пример объекта, который вы используете? Репродуктор был бы еще лучше. Вы можете использовать JBang, чтобы запустить тестовый пример:

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

Вы можете заменить idea своей любимой IDE

Неважно .... Я вижу исключение

для получения дополнительной информации мы используем LocalTime в Entity и TIME в базе данных.

Сущность
public class A { @Column(name = "time") private LocalTime time; }

Стол
CREATE TABLE IF NOT EXISTS A ( time TIME )

Таким образом, проблема здесь в том, что понятие зонированного _времени_ полностью нарушено и никогда не должно было вводиться в SQL (к счастью, большинство баз данных его не поддерживают). Отображение между часовыми поясами _зависит от даты_, поэтому имеют смысл только зонированные даты и время.

До этого момента я понятия не имел о поведении hibernate.jdbc.time_zone , которое, на первый взгляд, выглядит довольно плохо, и, возможно, мы должны изменить его в H6.

Так что я не уверен, что делать здесь. «Исправить» его, чтобы он делал то же самое, что и ORM, или просто игнорировать настройку при работе со временем?

Или просто проигнорируйте это свойство и выясните, как это сделать, используя вместо этого свойство соединения? (Возможно, нужна новая функция в клиенте Vert.x, я не уверен.)

Я удаляю ярлык "ошибка". Это не ошибка, что зонированное время не работает. Они сломаны _design_.

(Это, конечно, частично моя вина, что я не копнул глубже, когда делал #676, и заметил проблему с поведением hibernate.jdbc.time_zone .)

Я начал дискуссию здесь .

Отображение между часовыми поясами _зависит от даты_, поэтому имеют смысл только зонированные даты и время.

Хорошо, но они пытаются сохранить LocalTime , к которому не привязан часовой пояс и который не требует никакого преобразования.
Я что-то пропустил?

Но, похоже, это не то, что делает это свойство. В ORM он привязывает часовой пояс к вещи.

По крайней мере, мне кажется. (Мне никогда не удавалось полностью понять семантику этого метода JDBC.)

«Исправьте» это, чтобы делать то же самое, что и ORM

Думаю, я проверю, что делает ORM, и сделаю то же самое. Вероятно, это поведение, которое в любом случае ожидают пользователи, знакомые с ORM.

Думаю, я проверю, что делает ORM, и сделаю то же самое.

ахахаха о сладкое летнее дитя!

ORM вызывает метод JDBC с недокументированной семантикой.

(И, вероятно, ведет себя по-разному в каждой базе данных.)

Итак, резюмируя часть обсуждения с @yrodiere на Zulip:

1. Он говорит, что все эти вещи очень хрупкие (и, вероятно, сломанные) в ORM, отчасти потому, что все драйверы JDBC делают хрупкие и разные вещи.
2. То, что я решил сделать для обработки Timestamp с hibernate.jdbc.time_zone (который пытается преобразовать данный Timestamp в заданный часовой пояс перед передачей его клиенту Vert.x SQL), может или может быть ненадежным, но это определенно не кажется концептуально правильным для Time .

Таким образом, варианты: (1) просто молча игнорировать настройку, (2) взорваться, когда настройка присутствует, или (3) сделать что-то, что, как мы знаем, не работает.

Я склоняюсь к (2).

Я _предполагаю_, что мы могли бы продолжать делать то, что мы делаем в настоящее время для даты и времени, и просто игнорировать настройку, которая касается времени. Но, черт возьми, это равнозначно представлению новой и по-другому сломанной интерпретации функции, которая уже немного сломана. Бррр.

@pqab, почему именно вы используете этот параметр? Не могли бы вы разумно просто _не_ использовать его?

@pqab , почему _точно_ вы используете этот параметр? Не могли бы вы разумно просто _не_использовать это?

И тот же вопрос для @Ngosti2000

Честно говоря, я не ожидал, что это будет применяться к объектам, у которых нет часового пояса, например LocalTime .

Я подозреваю, что проблема в том, что это глобальное свойство, и если вы установите его, потому что это имеет смысл в других случаях, я не думаю, что есть способ отключить его для определенных полей. А может есть?

Честно говоря, я не ожидал, что это будет применяться к объектам, у которых нет часового пояса, например LocalTime .

Правильно, то же самое. Мы слишком надеялись на здравомыслие.

Я не думаю, что есть способ отключить его для определенных полей. А может есть?

Не то, что я знаю из.

у нас есть некоторые другие поля DATE , которым требуется глобальное свойство, но мы ожидали, что поле TIME следует игнорировать, потому что оно не имеет часового пояса

Сделанный