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を使用し、データベースでTIMEを使用しています

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

テーブル
CREATE TABLE IF NOT EXISTS A ( time 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メソッドを呼び出します。

（そして、おそらくデータベースごとに異なる動作をします。）

したがって、 Zulipでの@yrodiereとの議論の一部を要約すると：

1. 彼は、すべてのJDBCドライバーが壊れやすく、異なることを行うため、このようなものはすべてORMではそもそも非常に壊れやすい（そしておそらく壊れている）と言います。
2. hibernate.jdbc.time_zoneでTimestampを処理するために私が決めたこと（Vert.x SQLクライアントに渡す前に、指定されたTimestampを指定されたタイムゾーンに変換しようとします）または堅牢ではないかもしれませんが、 Timeの概念的には確かに正しくないようです。

したがって、オプションは、（1）設定を黙って無視する、（2）設定が存在するときに爆破する、または（3）壊れていることがわかっていることを実行することです。

私は（2）を使いたいと思っています。

私は、現在行っていることを日時に続けて、時間に関する設定を無視することができると思います。 しかし、そうねえ、それは、すでにちょっと壊れている機能の新しい、異なって壊れた解釈を導入することになります。 Brrr。

@pqabなぜこの設定を正確に使用するのですか？ 合理的に、たとえば、それを使用しないでください。

@pqabなぜこの設定を_正確に_使用するのですか？ 合理的に、たとえば、それを使用しないでください。

そして@Ngosti2000についても同じ質問

公平を期すために、 LocalTimeのようなタイムゾーンを持たないオブジェクトに適用されるとは思っていませんでした。

問題はそれがグローバルプロパティであることにあると思います。他の場合に意味があるために設定した場合、特定のフィールドに対して無効にする方法はないと思います。 または多分ありますか？

公平を期すために、 LocalTimeのようなタイムゾーンを持たないオブジェクトに適用されるとは思っていませんでした。

そうです、同じです。 私たちはあまりにも多くの正気を仮定しました。

特定のフィールドで無効にする方法はないと思います。 または多分ありますか？

私が知っていることではありません。

他にもDATEフィールドにはグローバルプロパティが必要ですが、 TIMEフィールドにはタイムゾーンがないため、無視する必要があると予想しました。

終わり