Hibernate-reactive: hibernate.jdbc.time_zone tidak didukung pada kolom TIME

Secara teori seharusnya sudah berfungsi :-)
https://github.com/hibernate/hibernate-reactive/issues/667

akan saya lihat

Bisakah Anda melewati contoh entitas yang Anda gunakan? Sebuah reproduksi akan lebih baik. Anda dapat menggunakan JBang untuk memulai contoh kasus uji:

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

Anda dapat mengganti idea dengan IDE favorit Anda

Tidak apa-apa .... Saya bisa melihat pengecualian

untuk lebih jelasnya, kami menggunakan LocalTime di Entity dan TIME di database

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

Meja
CREATE TABLE IF NOT EXISTS A ( time TIME )

Jadi masalahnya di sini adalah bahwa gagasan tentang _time_ yang dikategorikan sepenuhnya rusak dan seharusnya tidak pernah diperkenalkan dalam SQL (untungnya sebagian besar basis data tidak mendukungnya). Pemetaan antara zona waktu _tergantung pada tanggal_, sehingga hanya zona waktu yang masuk akal.

Sampai saat ini saya tidak tahu tentang perilaku hibernate.jdbc.time_zone , yang terlihat sangat buruk bagi saya, pada pandangan pertama, dan mungkin kita harus mengubahnya di H6.

Jadi saya tidak yakin apa yang harus dilakukan di sini. "Perbaiki" untuk melakukan hal buruk yang sama seperti ORM, atau abaikan saja pengaturan saat bekerja dengan waktu?

Atau abaikan saja propertinya, dan cari tahu cara melakukannya menggunakan properti koneksi? (Mungkin memerlukan fitur baru di klien Vert.x, saya tidak yakin.)

Saya menghapus label "bug". Bukan bug yang membuat zona waktu tidak berfungsi. Mereka rusak oleh _design_.

(Ini tentu saja sebagian kesalahan saya karena tidak menggali lebih dalam ketika saya melakukan #676 dan memperhatikan masalah dengan perilaku hibernate.jdbc.time_zone .)

Saya memulai diskusi di sini .

Pemetaan antara zona waktu _tergantung pada tanggal_, sehingga hanya zona waktu yang masuk akal.

Oke, tetapi mereka mencoba menyimpan LocalTime yang tidak memiliki zona waktu apa pun dan tidak memerlukan konversi apa pun.
Apakah saya melewatkan sesuatu?

Tapi sepertinya bukan itu yang dilakukan properti ini. Di ORM itu menempelkan zona waktu ke benda itu.

Setidaknya, menurut saya. (Saya tidak pernah bisa sepenuhnya memahami semantik metode JDBC itu.)

"Perbaiki" untuk melakukan hal buruk yang sama seperti ORM

Saya pikir saya akan memeriksa apa yang dilakukan ORM dan melakukan hal yang sama. Ini mungkin perilaku yang diharapkan oleh pengguna yang akrab dengan ORM.

Saya pikir saya akan memeriksa apa yang dilakukan ORM dan melakukan hal yang sama.

hahahaha oh anak musim panas yang manis!

ORM memanggil metode JDBC yang pada dasarnya memiliki semantik yang tidak terdokumentasi.

(Dan mungkin berperilaku berbeda di setiap database.)

Jadi untuk rekap bagian dari diskusi dengan @yrodiere di Zulip:

1. Dia mengatakan hal ini semua sangat rapuh (dan mungkin rusak) di ORM untuk memulai, sebagian karena semua driver JDBC melakukan hal-hal yang rapuh dan berbeda.
2. Apa yang saya putuskan untuk lakukan untuk menangani Timestamp s dengan hibernate.jdbc.time_zone (yang mencoba mengonversi Timestamp yang diberikan ke zona waktu yang diberikan sebelum meneruskannya ke klien Vert.x SQL) mungkin atau mungkin tidak kuat, tetapi tampaknya secara konseptual tidak benar untuk Time .

Jadi pilihannya adalah (1) diam-diam mengabaikan pengaturan, (2) meledakkan saat pengaturan ada, atau (3) melakukan sesuatu yang kita tahu rusak.

Saya cenderung untuk pergi dengan (2).

Saya _seandainya_ kita bisa terus melakukan apa yang sedang kita lakukan untuk datetimes, dan abaikan saja pengaturan waktunya. Tapi astaga, itu sama saja dengan memperkenalkan interpretasi baru dan berbeda dari fitur yang sudah agak rusak. brr.

@pqab mengapa tepatnya Anda menggunakan pengaturan ini? Bisakah Anda, seperti, hanya _tidak_ menggunakannya?

@pqab mengapa _tepatnya_ Anda menggunakan pengaturan ini? Bisakah Anda, seperti, _not_use saja?

Dan pertanyaan yang sama untuk @Ngosti2000

Agar adil, saya tidak berharap itu diterapkan pada objek yang tidak memiliki zona waktu seperti LocalTime .

Saya menduga masalahnya adalah bahwa ini adalah properti global dan jika Anda mengaturnya karena masuk akal dalam kasus lain, saya tidak berpikir ada cara untuk menonaktifkannya untuk bidang tertentu. Atau mungkin ada?

Agar adil, saya tidak berharap itu diterapkan pada objek yang tidak memiliki zona waktu seperti LocalTime .

Benar, sama. Kami berasumsi terlalu banyak kewarasan.

Saya tidak berpikir ada cara untuk menonaktifkannya untuk bidang tertentu. Atau mungkin ada?

Tidak yang saya tahu.

kami memiliki beberapa bidang DATE lainnya yang memerlukan properti global, tetapi kami berharap bahwa bidang TIME harus diabaikan karena tidak memiliki zona waktu

Selesai