Hibernate-reactive: hibernate.jdbc.time_zone TIME कॉलम पर समर्थित नहीं है

सिद्धांत रूप में यह पहले से ही काम करना चाहिए :-)
https://github.com/hibernate/hibernate-reactive/issues/667

मुझे एक नज़र डालनी है

क्या आप अपने द्वारा उपयोग की जा रही इकाई का एक उदाहरण पिछले कर सकते हैं? एक पुनरुत्पादक और भी बेहतर होगा। उदाहरण टेस्टकेस शुरू करने के लिए आप जेबींग का उपयोग कर सकते हैं:

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

आप idea को अपने पसंदीदा IDE से बदल सकते हैं

कोई बात नहीं.... मैं अपवाद देख सकता हूँ

अधिक विवरण के लिए, हम Entity में 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 में बदलना चाहिए।

तो मुझे यकीन नहीं है कि यहाँ क्या करना है। ओआरएम के समान खराब काम करने के लिए इसे "ठीक करें", या समय के साथ काम करते समय सेटिंग को अनदेखा करें?

या बस संपत्ति को पूरी तरह से अनदेखा करें, और इसके बजाय कनेक्शन संपत्ति का उपयोग करके इसे कैसे करें? (Vert.x क्लाइंट में एक नई सुविधा की आवश्यकता हो सकती है, मुझे यकीन नहीं है।)

मैं "बग" लेबल हटा रहा हूं। यह कोई बग नहीं है कि ज़ोन किया गया समय काम नहीं करता है। वे _design_ से टूट गए हैं।

(यह निश्चित रूप से आंशिक रूप से मेरी गलती है जब मैंने #676 किया था और hibernate.jdbc.time_zone के व्यवहार के साथ समस्या को देखते हुए गहरी खुदाई नहीं की थी।)

मैंने यहां एक चर्चा शुरू की।

टाइमज़ोन _ के बीच मैपिंग दिनांक_ पर निर्भर करती है, और इसलिए केवल ज़ोन किए गए डेटाटाइम ही समझ में आते हैं।

ठीक है, लेकिन वे एक LocalTime स्टोर करने की कोशिश कर रहे हैं जिसमें कोई टाइमज़ोन संलग्न नहीं है और किसी भी रूपांतरण की आवश्यकता नहीं है।
क्या मुझे कुछ याद नहीं आ रहा है?

लेकिन ऐसा नहीं है कि यह संपत्ति क्या करती है, ऐसा लगता है। ओआरएम में यह चीज़ को टाइमज़ोन जोड़ता है।

कम से कम मुझे तो ऐसा लगता है। (मैं उस JDBC पद्धति के शब्दार्थ को पूरी तरह से समझने में सक्षम नहीं हूँ।)

ओआरएम के समान खराब काम करने के लिए इसे "ठीक करें"

मुझे लगता है कि मैं जांच करूंगा कि ओआरएम क्या करता है और वही करता है। शायद यह व्यवहार है कि उपयोगकर्ता ओआरएम से परिचित हैं, वैसे भी उम्मीद करेंगे।

मुझे लगता है कि मैं जांच करूंगा कि ओआरएम क्या करता है और वही करता है।

हाहाहा ओह स्वीट समर चाइल्ड!

ओआरएम एक जेडीबीसी विधि को कॉल करता है जिसमें अनिवार्य रूप से अनियंत्रित अर्थशास्त्र है।

(और शायद हर डेटाबेस पर अलग तरह से व्यवहार करता है।)

तो ज़ूलिप पर @yrodiere के साथ चर्चा का हिस्सा फिर से बनाने के लिए:

1. उनका कहना है कि यह सामान ओआरएम में शुरू करने के लिए बहुत ही नाजुक (और शायद टूटा हुआ) है, आंशिक रूप से क्योंकि सभी जेडीबीसी ड्राइवर नाजुक और अलग-अलग चीजें करते हैं।
2. मैंने Timestamp s को hibernate.jdbc.time_zone के साथ संभालने के लिए क्या करने का फैसला किया (जो दिए गए Timestamp को Vert.x SQL क्लाइंट को पास करने से पहले दिए गए समय क्षेत्र में बदलने की कोशिश करता है) हो सकता है या मजबूत नहीं हो सकता है, लेकिन यह निश्चित रूप से Time के लिए अवधारणात्मक रूप से सही नहीं लगता है।

तो विकल्प हैं (1) बस चुपचाप सेटिंग को अनदेखा करें, (2) सेटिंग मौजूद होने पर उड़ा दें, या (3) कुछ ऐसा करें जो हम जानते हैं कि टूट गया है।

मैं (2) के साथ जाने के इच्छुक हूं।

मैं _मान लीजिए_ हम वह कर सकते हैं जो हम वर्तमान में डेटाटाइम के लिए कर रहे हैं, और बस उस सेटिंग को अनदेखा करें जो समय पर आती है। लेकिन गीज़, यह एक ऐसी सुविधा की एक नई और अलग-अलग टूटी हुई व्याख्या पेश करने की मात्रा है जो पहले से ही टूटा हुआ है। ब्र्रर

@pqab आप इस सेटिंग का सटीक उपयोग क्यों करते हैं? क्या आप यथोचित रूप से पसंद कर सकते हैं, बस _not_ इसका उपयोग करें?

@pqab क्यों _precisely_ आप इस सेटिंग का उपयोग करते हैं? क्या आप इसे यथोचित रूप से पसंद कर सकते हैं, बस इसे _not_use करें?

और @Ngosti2000 . के लिए भी यही सवाल

निष्पक्ष होने के लिए, मुझे उन वस्तुओं पर लागू होने की उम्मीद नहीं थी जिनके पास समय क्षेत्र नहीं है जैसे LocalTime ।

मुझे संदेह है कि समस्या यह है कि यह एक वैश्विक संपत्ति है और यदि आप इसे सेट करते हैं क्योंकि यह अन्य मामलों में समझ में आता है तो मुझे नहीं लगता कि विशिष्ट क्षेत्रों के लिए इसे अक्षम करने का कोई तरीका है। या शायद वहाँ है?

निष्पक्ष होने के लिए, मुझे उन वस्तुओं पर लागू होने की उम्मीद नहीं थी जिनके पास समय क्षेत्र नहीं है जैसे LocalTime ।

सही, वही। हमने बहुत अधिक विवेक ग्रहण किया।

मुझे नहीं लगता कि विशिष्ट क्षेत्रों के लिए इसे अक्षम करने का कोई तरीका है। या शायद वहाँ है?

मेरी जानकारी में नहीं।

हमारे पास कुछ अन्य DATE फ़ील्ड को वैश्विक संपत्ति की आवश्यकता है, लेकिन हमें उम्मीद थी कि TIME फ़ील्ड को अनदेखा कर दिया जाना चाहिए क्योंकि इसमें समय क्षेत्र नहीं है

पूर्ण