Hibernate-reactive: hibernate.jdbc.time_zone غير مدعوم في أعمدة TIME

من الناحية النظرية ، يجب أن تعمل بالفعل :-)
https://github.com/hibernate/hibernate-reactive/issues/667

سألقي نظرة

هل يمكنك تجاوز مثال على كيان تستخدمه؟ الناسخ سيكون أفضل. يمكنك استخدام JBang لبدء مثال testcase:

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 s مع hibernate.jdbc.time_zone (والذي يحاول تحويل Timestamp المعطى إلى المنطقة الزمنية المحددة قبل تمريره إلى عميل Vert.x SQL) قد أو قد لا تكون قوية ، لكنها بالتأكيد لا تبدو صحيحة من الناحية المفاهيمية لـ Time .

لذا فإن الخيارات هي (1) تجاهل الإعداد بصمت ، (2) التفجير عند وجود الإعداد ، أو (3) القيام بشيء نعلم أنه معطل.

أنا أميل إلى الذهاب مع (2).

أؤيد أنه يمكننا الاستمرار في فعل ما نقوم به حاليًا في أوقات محددة ، وتجاهل الإعداد الذي يتعلق بالأوقات. لكن الجيز ، هذا يرقى إلى تقديم تفسير جديد ومخالف بشكل مختلف لميزة معطلة بالفعل نوعًا ما. بررر.

pqab لماذا بالضبط تستخدم هذا الإعداد؟ هل يمكنك ، بشكل معقول ، ألا تستخدمه فحسب؟

pqab لماذا _precely_ تستخدم هذا الإعداد؟ هل يمكنك ، بشكل معقول ، ألا تستخدمه فحسب؟

ونفس السؤال عن @ Ngosti2000

لكي نكون منصفين ، لم أتوقع أن يتم تطبيقه على الكائنات التي ليس لها منطقة زمنية مثل LocalTime .

أظن أن المشكلة تكمن في أنها خاصية عالمية وإذا قمت بتعيينها لأنها منطقية في حالات أخرى لا أعتقد أن هناك طريقة لتعطيلها في حقول معينة. أو ربما يوجد؟

لكي نكون منصفين ، لم أتوقع أن يتم تطبيقه على الكائنات التي ليس لها منطقة زمنية مثل LocalTime .

نفس الشيء. افترضنا الكثير من العقل.

لا أعتقد أن هناك طريقة لتعطيله لحقول محددة. أو ربما يوجد؟

ليس هذا ما أعلمه عن.

لدينا بعض الحقول الأخرى DATE تحتاج إلى الخاصية العالمية ، لكننا توقعنا أن الحقل TIME يجب أن يتم تجاهله لأنه لا يحتوي على منطقة زمنية

منجز