Jdbi: يتجاهل مخطط الخرائط المضمن لـ ZonedDateTime معلومات المنطقة الزمنية

أنت على صواب ، لكن هذا هو كل ما تدعمه JDBC في هذا الوقت. يتعين علينا تحويل جميع أنواع java.time إلى أنواع java.util أو java.sql التي تفتقر إلى بيانات المنطقة الزمنية / الإزاحة.

بدافع الفضول ، هل تستخدم Postgres؟ لأن TIMESTAMP WITH TIME ZONE يتصرف بشكل مختلف عما كنت تتوقعه.

هل تستخدم Postgres؟ لأن TIMESTAMP WITH TIME ZONE يتصرف بشكل مختلف عما كنت تتوقعه.

انا على درايه. (خيبة أمل كبيرة لقاعدة بيانات متوافقة للغاية مع المعايير راجع للشغل.)

أنت على صواب ، لكن هذا هو كل ما تدعمه JDBC في هذا الوقت.

كنت أتوقع أن تقوم JDBI بسحب H2 org.h2.api.TimestampWithTimeZone دون الحاجة إلى القيام بذلك يدويًا ، بطريقة ما.
نظرًا لأنني لا أعرف أي طريقة "محمولة" (تعمل عبر برامج تشغيل مختلفة) لسحب قيمة TIMESTAMP W / TZ ، فليس لدي أي حل حقيقي.
ومع ذلك ، إذا لم تقم بسحب جميع المعلومات ، فلا يجب أن تتظاهر بأنك تفعل ذلك - على سبيل المثال ، يجب ألا يكون هناك مخطط خرائط مدمج لـ IMO لـ ZonedDateTime . وإلا فأنت تفعل تمامًا مثل Postgres - وليس ما كنت أتوقعه.

أعتقد أنه لا يزال من الملائم إذا أراد المستخدم استخدام ZonedDateTime ولا يهتم بإعادته في المنطقة الزمنية لخادم التطبيق بدلاً من المنطقة الزمنية لقاعدة البيانات.

بالمناسبة ، يستخدم Dropwizard إصدارًا مختلفًا من مصمم الخرائط لـ JDBI2 ، حيث يمكن للمستخدم تعيين المنطقة الزمنية لقاعدة البيانات بشكل صريح: https://github.com/dropwizard/dropwizard/blob/master/dropwizard-jdbi/src/main/java /io/dropwizard/jdbi/args/ZonedDateTimeMapper.java

إذا كان بإمكانك تقديم رمز مثال لكيفية الحصول على / تعيين ZonedDateTime مع H2 ، فسيسعدني إضافة ذلك إلى المكون الإضافي.

أعتقد أنه لا يزال من الملائم إذا أراد المستخدم استخدام ZonedDateTime ولا يهتم بإعادته في المنطقة الزمنية لخادم التطبيق بدلاً من المنطقة الزمنية لقاعدة البيانات.

arteam ، إذا كان المستخدم على علم باتخاذ هذا الاختيار - أوافق.

ومع ذلك ، فإن AFAIR https://github.com/jdbi/jdbi/blob/master/core/src/main/java/org/jdbi/v3/core/mapper/BuiltInMapperFactory.java#L182 لن يعمل حتى على H2 لـ TS w TZ ، لأن rs.getTimestamp(..) غير مدعوم لهذا النوع.

إذا كان بإمكانك تقديم رمز مثال لكيفية الحصول على / تعيين ZonedDateTime مع H2 ، فسيسعدني إضافة ذلك إلى المكون الإضافي.

لا أعرف بأي طريقة محمولة - الطريقة الوحيدة التي أعرفها هي (org.h2.api.TimestampWithTimeZone) rs.getObject(..) وعلى سبيل المثال Oracle ستكون مشابهة ، ولكن مع فئة خاصة بـ Oracle.

بشكل عام ، أفضل أن يتم فرض _ فرض_ بواسطة واجهة برمجة التطبيقات لاستخدام التحويل الصحيح (الطابع الزمني إلى LocalDateTime ) وإضافة "zone-ing" بشكل صريح.

يبدو أنك غير موافق ، مما يعني أنه لا فائدة من إبقاء هذه القضية مفتوحة.

شيء واحد نقوم به في مكدسنا ، نحن في الواقع نؤكد أن المنطقة الزمنية لجافا == المنطقة الزمنية لـ Postgres ، وفي هذه الحالة كل شيء يعمل بشكل صحيح. هل يجب أن نصدر تحذيرًا إذا كان هناك عدم تطابق؟ هل سيكون ذلك بمثابة حل وسط جيد بين تمكين الميزات التي يتوقعها الأشخاص ، وبين أن تكون على صواب TZ؟

لست متأكدًا من سبب إغلاق هذا بسرعة ، شعرت أن هناك المزيد للمناقشة.

حتى إذا لم نتمكن من حل هذا بشكل عام لجميع البائعين ، يمكننا بالتأكيد دعم هذا على أساس كل بائع.

يمكن تجاوز مصممي الخرائط والمعامل التي تشحن مع Jdbi ببساطة عن طريق تسجيل مخطط / وسيطة أخرى. آخر تسجيل (لكل نوع) يفوز.

إذا نظرت إلى مصدر PostgresPlugin ، فسترى أنه يسجل JavaTimeMapperFactory والذي يوفر مصممي خرائط بديلين باستخدام ResultSet.getObject(Class) مقابل LocalDate ، LocalTime و LocalDateTime و OffsetDateTime ، وهي مدعومة مباشرة بواسطة برنامج تشغيل Postgres JDBC.

إذا كان لدى H2 طريقة لتخزين ZonedDateTime دون حذف المنطقة ، فيمكننا تعديل H2DatabasePlugin لاستخدام مخطط مخصص لذلك.

سأعيد فتح هذا الآن ، هناك مناقشة جيدة ستتم هنا ، و

هل أفهم بشكل صحيح من هذا المحدِّد أن فريق jdbi سيكون مهتمًا بالحصول على مثال jdbi3-hsqldb subproject / artifact / ... الذي يوفر الحجج ورسمي الخرائط خصيصًا لـ hsqldb (الذي يدعم استخدام كائنات java.time مباشرة من خلال setObject / getObject بدون التحويل)؟

على الاطلاق.

لأكون صادقًا ، أتفق مع

أفضل اكتشاف استثناء لوقت التشغيل أثناء تشغيل اختباري أن jdbi لا يوفر مخططًا لنوع معين ثم اكتب واحدًا بنفسي ، بدلاً من معرفة من يعرف متى تم تغيير مصمم الخرائط المقدم من jdbi بشكل خفي بياناتي.

لدي اختبار وحدة كبير يكتب ثم يقرأ قيمًا من أنواع عديدة ، للتحقق من صحة التنفيذ / تكامل البيانات في كل من db نفسه (hsqldb) و jdbi ، لذلك يمكنني كتابة مخططات / وسيطات jdbi للتعامل مع أي مشكلات. لقد اضطررت إلى كتابة العديد الآن لأن hsqldb ليس لديه حاليًا أي دعم لـ java.time على الرغم من المواصفات التي تقول ذلك (خطأ كبير). لم أفكر في اختبار كائنات java.time مع مناطق / إزاحات أخرى غير نظامي واحد حتى الآن ، لذلك فعلت للتو ، وبالتأكيد ، عادوا جميعًا مع إعادة تعيين الإزاحة / المنطقة إلى قيم النظام ، ولكن بسبب تعيين jdbi إلى الطابع الزمني ، وليس بسبب أخطاء hsqldb.

أقترح إزالة رسامي الخرائط المعيب هؤلاء من jdbi3 ونقلهم إلى القطع الأثرية الخاصة بالبائع (jdbi3-hsqldb وغيرها) حيث يمكن جعل تنفيذها صحيحًا تمامًا.

قد أكون قادرًا على المساهمة في jdbi-hsqldb بنفسي لأنني كتبت بالفعل جميع رسامي الخرائط والحجج اللازمة لمشروعي الخاص على أي حال.

أوافق على أنه ربما كان المسار الأكثر حكمة ، ولكن في هذه المرحلة ، تم إطلاق الإصدار 3 والقط خارج الحقيبة.

قد تكون إزالة مصممي الخرائط أو المصانع الوسيطة تغييرًا جذريًا لأي مستخدمين حاليين يعتمدون عليهم.

إذا كان شخص ما يعتمد عليهم بالفعل (مدركًا لعيوبهم أم لا) ، فأنا أعتقد أنه سيكون من السهل جدًا لهؤلاء المستخدمين تصحيحها مرة أخرى: التحويلات هي إلى حد كبير سطر واحد. من ناحية أخرى ، سيؤدي الاحتفاظ بها إلى المزيد والمزيد من الأشخاص مثلي الذين يفترضون أنها تعمل لأنها متوفرة (بصراحة ، من يعرف جميع المواصفات الفنية مثل عدم دعم jdbc للمناطق الزمنية عن ظهر قلب؟) وربما اكتشفوا لاحقًا أنه تم التعامل مع بياناتهم بشكل سيء ...
في الأساس ، أعتقد أن الضرر المستقبلي المحتمل من خلال السماح لهم بالبقاء أكبر بكثير من الضرر الذي لحق الآن بالقلة الذين قاموا بالتحديث عن طريق إزالتها.

TheRealMarnes أعتقد أن إزالة ميزة (حتى عندما نتفق على عدم وجودها) ليست بهذه البساطة. يميل الناس إلى افتراض الإصدار الدلالي (بغض النظر عما إذا كان المشروع يتبعه أم لا). لا أعرف قواعد المشروع ، ولكن عادةً ما تقوم بإهماله على الأكثر في الإصدار 3 (يعد الإيقاف هنا أمرًا صعبًا ، لأنه لا توجد طريقة واجهة برمجة تطبيقات يمكن تمييزها كمتجاهلة ، وما تبقى من التوثيق والتسجيل) وإزالة الميزة في الإصدار 4 ، توقع أن يقرأ الناس ملاحظات الإصدار / دليل الترحيل.

أوافق على أن شيئًا من هذا القبيل ليس بسيطًا أبدًا وأن الحلول ستجعل دائمًا شخصًا غير سعيد ، لكنني أميل إلى الاعتقاد بأن الغاية تبرر الوسيلة وإزعاج نظام معيب لاستبداله بنظام أفضل هو دائمًا يستحق الانزعاج على المدى الطويل. ولا أعتقد أن توقع قراءة ملاحظات الإصدار / دليل الترحيل أمر غير معقول ... مع الصيانة والتحديثات الطفيفة ، بالتأكيد ، ولكن ليس مع تحديث رئيسي. Jdbi3 نفسه غير قابل للاستخدام من jdbi2 دون قراءة الدليل الجديد أيضًا.

أعتقد أنه يمكنني الحصول على حل لتعطيل هؤلاء مصممي الخرائط / الوسائط ، بشرط أن تكون إعادتهم سطرًا واحدًا - ربما نقل هؤلاء مصممي الخرائط إلى مكون إضافي؟

مثل jdbi3-core-experimental غير خاص بالبائع؟
تحرير: سيئتي ، تقصد jdbi.installPlugin(new ExperimentalMappersPlugin())

ستكون هذه هي الفكرة ، على الرغم من أن هذه ليست "تجريبية" حقًا على هذا النحو.

TimezoneInsensitiveJavaTimeMappers ثم: P

لا يقتصر الأمر على مصممي الخرائط فحسب ، بل هم أيضًا مصانع الحجج.

ماذا عن JavaTimeYoloTZPlugin : wink:

حتى إذا لم نتمكن من حل هذا بشكل عام لجميع البائعين ، يمكننا بالتأكيد دعم هذا على أساس كل بائع.

علمت qualidafial مؤخرًا أنه يبدو أن هناك معيارًا واقعيًا ناشئًا لاسترداد قيم التاريخ / الوقت في عالم ما بعد Java8.

أولاً ، خلفية أكثر قليلاً:

• لقد قمت بإنشاء هذه المشكلة حول تحويل JDBI TIMESTAMP WITH TIME ZONE إلى ZonedDateTime ، والذي يتجاهل معلومات المنطقة الزمنية
• هناك مشكلة أخرى ، مع جميع JDBC API. هذه هي الطريقة التي من المفترض أن يتم استرجاعها TIMESTAMP ، DATE ، TIME ، أي باستخدام فئات java.sql.{Timestamp,Date,Time} . تمتد جميع الفئات من java.util.Date . هل يتذكر أي شخص كيف تم تقديم Calendar وطرق java.util.Date تتعامل مع السنة / الشهر / اليوم / الساعة / الدقيقة / الثانية حيث تم إهمالها؟ لسبب وجيه لذلك (وأنا لا أعني Calendar حل جميع المشاكل).
  
  
  
  • لا يمكنك استرداد java.sql.Timestamp من قاعدة بيانات ، إذا لم تلتزم المنطقة الزمنية _JVM الخاصة بك بمثل هذا التوقيت المحلي. لذلك يمكن لتطبيق قيد التشغيل في الولايات المتحدة تخزين قيمة طابع زمني بقيمة 2017-03-26 02:30:00 (بدون منطقة!) في بعض قواعد البيانات المشتركة ، لكن التطبيق الذي يتم تشغيله في أوروبا (على سبيل المثال Europe/Berlin كمنطقة JVM) لن تكون قادرًا على استرداد هذا الطابع الزمني ، نظرًا لوجود التوقيت الصيفي في أوروبا في ذلك الوقت.
  
  
  • أوه ، الأمر نفسه ينطبق على java.sql.Date ، لأن هذه فئة متطابقة تقريبًا. java.sql.Date التاريخ تمامًا كما لو كان java.sql.Timestamp عند منتصف الليل ، لكن في بعض الأحيان لا يكون هناك منتصف الليل. هناك مناطق بها تغييرات التوقيت الصيفي في منتصف الليل (سواء الحالية أو في الماضي).
  
  
  • هل تعتقد أن java.sql.Time خالٍ من هذه المشكلة ، لأنه يمثل الوقت المسترجع كطابع زمني بتاريخ 1970-01-01؟ للأسف لا ، نظرًا لوجود مناطق كانت لطيفة بما يكفي لتغيير السياسة في ذلك التاريخ (على سبيل المثال ، America/Bahia_Banderas ، America/Hermosillo ). إذا كانت JVM واحدة إذا كانت هذه المناطق ، فلن يتمكن برنامج يستخدم JDBC من استرداد قيم معينة TIME .
  
  

لن يكون الحل هو الاسترداد باستخدام واجهة برمجة تطبيقات JDBC القديمة وتحويلها إلى فئات جديدة. لكن هذا خطأ بشكل عام:

• ~ resultSet.getTimestamp(col).toLocalDateTime() ~
• ~ resultSet.getDate(col).toLocalDate() ~
• ~ resultSet.getTime(col).toLocalTime() ~

يجمع هذا ويعمل بشكل جيد ، إلا أن هذا لا يحل أيًا من المشكلات الموضحة أعلاه (حتى تاريخ الاسترداد لا يعمل ، إذا كانت منطقة JVM هي Pacific/Apia والتاريخ المسترجع هو 2011-12-30 ؛)

الآن ، إلى الحل الناشئ. ResultSet على واجهة برمجة التطبيقات (API) الأقل شهرة والتي تسمح لك بمطالبة برنامج تشغيل JDBC بتحويل النوع نيابةً عنك:

• resultSet.getObject(col, LocalDateTime.class) // for TIMESTAMP
• resultSet.getObject(col, LocalDate.class) // for DATE
• resultSet.getObject(col, LocalTime.class) // for TIME
• resultSet.getObject(col, ZonedDateTime.class) // for TIMESTAMP WITH TIME ZONE

يبدو أن هذا يعمل مع برامج تشغيل JDBC لـ PostgreSQL و MySQL و Oracle و H2. ويتغلب السحر على مشاكل "عدم التمثيل في منطقة JVM" الموضحة أعلاه.
على الرغم من أن هذا التحويل لم يتم تنفيذه بعد في برنامج تشغيل SQL Server ، أعتقد أنه يمكن إجراء ذلك _the_ التعيين الافتراضي لفئات Java Time التي يشحنها JDBI.

ملحوظة:
لا تتطلب مواصفات JDBC 4.2 أن يقوم برنامج التشغيل بتنفيذ ذلك. ومع ذلك ، تتطلب المواصفات قبول PreparedStatement.setObject و RowSet.setObject مثيلات فئات Java Time ومعالجتها بشكل صحيح ، لذلك يحتاج السائقون إلى دعم هذه الفئات بشكل صريح على أي حال.

هذا بارد! قلقي الرئيسي هو أن التغيير في هذا النهج يمكن أن يظهر على أنه تراجع للمستخدمين الذين يستخدمون برامج تشغيل مقصورة على فئة معينة. ولكن ربما من خلال الرسائل المناسبة في ملاحظات الإصدار ، يمكننا إجراء هذا التغيير الطفيف تقنيًا في اسم القيام بالأشياء بالطريقة الصحيحة ...

stevenschlansker أنت على حق. أعتقد أن JDBI يمكن أن تقدم

• مجموعة اختيارية من التعيينات التي يمكن للمستخدم توصيلها لاستعادة السلوك الأصلي
• بعض التعليقات المناسبة في ملاحظات الإصدار (أو حتى عثرة في الإصدار الرئيسي)

دعنا نحتفظ بها في إصدار ثانوي ، لقد أصدرنا للتو 3 ، وهذا مجرد تغيير جذري إذا كنت تعتقد أنه خطأ ... ؛)

فقط لتشغيل ما يبدو كما لو كنت أسمعه:

• انقل مصممي java.time المدمجين الحاليين إلى مكون إضافي منفصل (أحب YoloTimePlugin )
• أضف مصممين خرائط مضمنين جدد في مكانهم يستخدمون ResultSet.getObject(column, type) بدلاً من التحويل من أنواع java.sql.
• توثيق الهراء الناتج عن هذا التغيير الفاصل في ملاحظات الإصدار: اشرح تأثير هذا التغيير وموردي قواعد البيانات الذين سيتأثرون ، وما يتعين على المستخدمين القيام به للتخفيف من المشكلات

يمكنني الحصول على وراء ذلك.

ما زلنا لم نجب على السؤال حول ربط كائنات التاريخ / الوقت هذه بالرغم من ذلك. أي شيء نغيره بخصوص نتائج التعيين _ out of_ قاعدة البيانات يجب أن يتم عكسه بالطريقة التي نربط بها وسيطات التاريخ / الوقت _into_ عبارات SQL.

أي شيء نغيره بشأن تعيين النتائج خارج قاعدة البيانات يجب أن ينعكس في الطريقة التي نربط بها وسيطات التاريخ / الوقت في عبارات SQL.
qualidafial ، سؤال جيد جدا. لم أختبر هذا. هذا مشمول صراحة من خلال مواصفات JDBC 4.2 ، لذا يجب أن يعمل فقط ™ _.

هذا مشمول صراحة من خلال مواصفات JDBC 4.2 ، لذا يجب أن يعمل فقط ™ _.

هذا يفترض أن منفذي برنامج تشغيل JDBC يتبعون المواصفات بشكل مثالي. لم أجد بعد تنفيذ برنامج تشغيل JDBC بدون أخطاء.

لدي شعور بأنه سيكون من المرهق جدًا توفير مكونات إضافية مع مصممي الخرائط لكل قاعدة بيانات وحتى إصداراتها المختلفة التي لها دعم مختلف لأنواع البيانات. ربما ينجح نهج قائمة فارغة أكثر: تبدأ بمثيل Jdbi بدون تثبيت مسبق لرسامين الخرائط ، وتوفر الأداة الأساسية مجموعة من مصممي الخرائط المختلفين الذين يمكنك انتقاءهم يدويًا لتثبيتها ، وبعضها له منطق مختلف للتعامل مع نفس أنواع البيانات - احصل على / setObject ، و get / setX ، والتحويل إلى نوع آخر ، وما إلى ذلك. ستحتاج إلى معرفة أفضل مصممي الخرائط لقاعدة البيانات الخاصة بك (الإصدار) ومنطق التطبيق ، واستخدام اختبارات الوحدة لإبقائها قيد الفحص.

هذا في الأساس ما أفعله الآن على أي حال في مشروعي. هناك بعض مصممي الخرائط المثبتين مسبقًا في Jdbi ولا يعملون مع db الخاص بي ولست بحاجة إليهم في الوقت الحالي ، لذلك قمت بالفعل بتجاوزهم بمصانع الحجة / مصمم الخرائط التي تطرح UnsupportedOperationException ، وأخرى قمت بتجاوزها باستخدام أفضل تطبيقات (انظر أدناه).

سيكون هذا حلاً لأولئك الذين يرغبون في التعامل مع db الخاص بهم للتأكد من أن كل شيء يعمل تمامًا ، ولن يغير شيئًا للأشخاص الذين يريدون أشياء إلى Just Werk ™ (بقدر ما يحدث في الواقع):

• إضافة طريقة إلى مثيلات Jdbi لمسح جميع مصممي الخرائط / الوسيطات (قائمة نظيفة)
• فضح المعين المدمج الحالي / arg يشير إلينا لتثبيته يدويًا
• استمر في إضافة رسام خرائط بديل إلى الأداة الأساسية عندما يزداد الطلب عليها والسماح للأشخاص بتثبيتها بأنفسهم ، مما ينتج عنه ما هو ممكن كما هو موضح أدناه

من خلال القيام بذلك ، تمكنت من العثور على ... الكثير من النقاط في برنامج التشغيل hsqldb حيث تنحرف عن المواصفات الخاصة بها (تم الإبلاغ عنها وتثبيتها في المصدر ، وما زلت تنتظر حتى تنشر أخيرًا أداة محدثة) ، وعملت حول هذه العيوب من خلال إيجاد منطق رسم الخرائط بنفسي.

// I want strings handled differently
<strong i="13">@Component</strong>
public class CleanStringArgumentFactory extends AbstractArgumentFactory<String> {
    protected CleanStringArgumentFactory() {
        super(Types.VARCHAR);
    }

    <strong i="14">@Override</strong>
    protected Argument build(String value, ConfigRegistry config) {
        return (position, statement, ctx) -> statement.setString(position, StringUtils.trimToNull(value));
    }
}

// no need for jdbi's built-in logic
<strong i="17">@Component</strong>
public class SetObjectArgumentFactory implements ArgumentFactory {
    private static final Set<Type> SUPPORTED = ImmutableSet.of(UUID.class, LocalDateTime.class);

    <strong i="18">@Override</strong>
    public Optional<Argument> build(Type type, Object value, ConfigRegistry config) {
        return SUPPORTED.contains(type)
            ? Optional.of(new LoggableArgument(value, (position, statement, context) -> statement.setObject(position, value)))
            : Optional.empty();
    }
}

// these built-ins don't work and I don't need them anyway
<strong i="21">@Component</strong>
public class UnsupportedArgumentFactory implements ArgumentFactory {
    private static final Set<Type> UNSUPPORTED = ImmutableSet.of(ZonedDateTime.class, OffsetDateTime.class, OffsetTime.class);

    <strong i="22">@Override</strong>
    public Optional<Argument> build(Type type, Object value, ConfigRegistry config) {
        if (UNSUPPORTED.contains(type)) {
            throw new UnsupportedOperationException(type.getTypeName() + " is not supported at the moment");
        } else {
            return Optional.empty();
        }
    }
}

// voodoo
<strong i="25">@Inject</strong>
    public JdbiConfiguration(
        @Named("dataSource") DataSource dataSource,
        Set<ArgumentFactory> arguments,
        Set<ColumnMapper> mappers,
        Set<ColumnMapperFactory> mapperFactories
    ) {
        jdbi = Jdbi.create(dataSource);
        jdbi.clearMappings();

        jdbi.installPlugin(new SqlObjectPlugin());

        arguments.forEach(jdbi::registerArgument);
        mapperFactories.forEach(jdbi::registerColumnMapper);
        mappers.forEach(jdbi::registerColumnMapper);

        // ...

        // Jdbi instance fine-tuned for my exact database and demands, without surprises and at my own responsibility

حوبودة؟ يمكنك على سبيل المثال توفير SetObjectArgumentFactory الذي يحتاج إلى التهيئة مع مجموعة من الفئات التي يجب أن يتم تنشيطها عليها ، وجميع أنواع الاختلافات في منطق التعيين للعديد من أنواع البيانات ، مع بعض السلوك القابل للتكوين حيثما أمكن ذلك. الجميع سعيد. يتطلب الأمر بعض العمل من المستخدم النهائي ، لكنني أشعر بالرضا لأن jdbi يفعل بالضبط ما أريده أن يفعله وما تدعمه قاعدة البيانات الخاصة بي.

لدي شعور بأنه سيكون من المرهق جدًا توفير مكونات إضافية مع مصممي الخرائط لكل قاعدة بيانات وحتى إصداراتها المختلفة التي لها دعم مختلف لأنواع البيانات.

أرغب في الحصول على مكونات إضافية للعديد من بائعي قواعد البيانات. تعال ، تعال جميعًا: إذا كانت قاعدة البيانات الخاصة بك تحتاج / تريد بعض التخصيصات لتكييف Jdbi مع خصوصيات بائع قاعدة البيانات أو برنامج تشغيل JDBC الخاص به ، فنحن نريد أن نسمع عنه. أو الأفضل من ذلك ، نريد طلبات سحب! :)

نقاط المكافأة إذا كانت قاعدة البيانات الخاصة بك مدعومة مباشرة من قبل TravisCI حتى نتمكن بالفعل من إجراء اختبارات ضدها: https://docs.travis-ci.com/user/database-setup/

بالنسبة إلى اقتراح "قائمة فارغة" ، لدي اعتراضات بسيطة فقط:

• ربما أضع طريقة clearMappings() مباشرة على فئات التكوين RowMappers و ColumnMappers و Arguments و JdbiCollectors بدلاً من Jdbi ، وأود أن أسميهم clear() .
• أنا متردد بعض الشيء في جعل رسامي الخرائط والحجج وجامعي الخرائط المدمجين عامًا. البعض منهم لديه أسماء أو تصميمات متزعزعة نتخلص منها لأنها داخلية. ربما أرغب في إعادة تشكيل بعضها قبل جعلها جزءًا من واجهة برمجة التطبيقات.
• أنا أتساءل عما إذا كان اللوح الفارغ ضروري حقًا. تستخدم جميع فئات التسجيل في Jdbi نهج آخر مكاسب مسجلة ، لذلك من الممكن دائمًا تجاوز السلوك خارج الصندوق. بهذا المعنى ، فإن اللوح الفارغ يبدو مبالغة قليلاً.

@ jdbi / المساهمون هل يهتم أي شخص آخر بالمشاركة؟

لقد قمت بتضمين فكرة القائمة الفارغة لتجنب استخدام مصمم الخرائط الافتراضي عن طريق الخطأ في حالة نسيان تسجيل أحد اختيارك. أفضل استخدام NotImplementedException بدلاً من الضمني الافتراضي. المكاسب الأخيرة جيدة وكل شيء ، ولكن لا توجد طريقة لمعرفة أي منها تحتاج إلى نقضه في حالة عدم رغبتك في ذلك.

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

أوافق على أنه لا ينبغي لنا فقط نشر مصممي الخرائط الحاليين. إذا اخترنا تقديم خيار قائمة نظيفة ، فيجب علينا تجميع مصممي الخرائط والمجلدات في قطع معقولة Plugin ، PrimitivesPlugin ، BoxedPrimitivesPlugin ، CollectionsPlugin ، أيا كان.

بعد ذلك ، يمكننا إضافة مصنع جديد لـ jdbi "الأساسي" بدون تكوين على الإطلاق ، وتعديل المصانع الحالية لاستخدام هذا وإضافة WholeJdbiEnchiladaPlugin .

أنا إلى حد ما ضد "clear" ما لم نتمكن من إظهار الحالات التي يصعب فيها إنشاءها بشكل إضافي - يبدو الأمر وكأنه رائحة كود بالنسبة لي.

أنا إلى حد ما ضد "clear" ما لم نتمكن من إظهار الحالات التي يصعب فيها إنشاءها بشكل إضافي - يبدو الأمر وكأنه رائحة كود بالنسبة لي.

حسنًا ، إذا أضفت مصنعًا منفصلاً لـ jdbi بدون تكوين مسبق ، فلن يكون من الصعب بناؤه بشكل إضافي ، لذلك لن نحتاج إلى أي مصنع واضح () بالفعل.

حسنًا ، أعتقد أننا متفقون هنا ، لقد كنت أعبر للتو عن تفضيل بإضافة طريقة مصنع "نظيفة" جديدة على نمط clear() .

إذن ، هل هذا يحل مشاكل الجميع إذن؟ أنا شخصياً أعتقد أن الخطة تبدو مثيرة للغاية.

• جعل Jdbi بدون قيم افتراضية (يطرح استثناءات على كل شيء تقريبًا)
• جعل جميع مصممي الخرائط والمجلدات الحالية (ومعالجات TX وما إلى ذلك) قابلة للتوصيل ( PrimitivesPlugin ، BoxedPrimitivesPlugin ، إلخ) ، كحزم إضافية وكفئات فردية
• تقديم بعض عمليات التنفيذ البديلة ( UTCJavaTimePlugin مقابل LocalJavaTimePlugin مقابل ConvertJavaTimeToUtilDatePlugin ، GetObjectMapper.forClasses(Class... cs) ، SetObjectArgumentFactory.forClasses(Class... cs) ، NullsToDefaultsPrimitivesPlugin مقابل NullThrowsExceptionPrimitivesPlugin ) وفضحهم بنفس الطريقة (في المكونات الإضافية وبشكل فردي) ، حتى يتمكن الأشخاص من تكوين منطق التعيين الإجمالي المطلوب ، مع أخذ ما يريدون بالضبط فقط. من المحتمل أن يكون هناك الكثير من تكوين مصمم الخرائط ضروريًا هنا ، مثل الاستراتيجيات المختلفة للتعامل مع القيم الخالية غير القانونية أو المناطق الزمنية المفقودة ، والتباينات المحتملة الأخرى
• ربما يصنعون إضافات حزمة خاصة بـ db ، بحيث يمكن للمستخدمين الذين لديهم إصدارات + قواعد بيانات شائعة البدء من no-config Jdbi وتثبيت خط واحد معروف مخططات تعيين جيدة لـ db ( HsqlDb2_4_0Plugin ) ، مرة أخرى مع خيارات التكوين لاستراتيجيات مختلفة
• وجعلها متوافقة مع الإصدارات السابقة فقط من خلال جعل طرق المصنع الحالية تؤدي التكوين المسبق لدينا الآن ( BuiltInGenericPreconfigurationPlugin ) ، إلى جانب طرق المصنع no-config.

جعل Jdbi بدون قيم افتراضية

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

سيحتاج المستخدمون إلى فهم التعيينات المختلفة الممكنة للأنواع التي يريدون استخدامها واختيار المناسب

لا ، فقط إذا أرادوا ذلك. ستستمر طرق المصنع الحالية في إخراج مثيلات Jdbi باستخدام نفس مصممي الخرائط المثبتين مسبقًا بالضبط كما يفعلون الآن. سنحصل بالإضافة إلى ذلك فقط على طرق مصنع التكوين الذاتي ، وسيحتاج الأشخاص الذين يختارون هذه الأساليب إلى معرفة الأمور الحميمة في رسم الخرائط. سيكون هناك منتصف الطريق أيضًا ، حيث تحصل على مثيل DIY وقم فقط بتثبيت YourDbAndVersionPlugin ولف كل ما يفعله. كان توضيحي المطول في الغالب عبارة عن استخدامات jdbi الداخلية والاستخدام المتقدم ، وليس خط الأساس.

TLDR: ستظل قادرًا على القيام بـ Jdbi.create(dataSource) ولن تحتاج إلى إعطاء أي صيحات إضافية حول هذا الموضوع لم تقدمها بالفعل. شخص آخر سيختار فقط Jdbi.createBlank(dataSource).install(x).install(y).install(z)...

أنا على متن الطائرة ، باستثناء أنني لا أعتقد أنه يجب علينا إهمال المصانع الحالية ، أعتقد أن معظم المستخدمين سيستمرون في استخدامها لأن السلوك "خارج الصندوق" جيد جدًا.

عادل بما يكفي

TheRealMarnes بدأت هذه المحادثة بأكملها بالتعامل مع أنواع بيانات JSR-310 التي لا تدعمها JDBC مباشرة.

أعتقد أن هناك إجماعًا حول إزالة مخططي java.time والحجج الخاطئة ، ووضعها في مكون إضافي بدلاً من تضمينها.

هل مازلت تريد متابعة ذلك؟

فقط منها java.time؟ JavaTimePlugin؟

نعم ، مكوّن إضافي لأنواع java.time فقط ، ولكن تم تسميته للتعبير عن أن الوسيطات ورسمي الخرائط هي تطبيقات ساذجة وفقد البيانات كما وصفها

SimplisticJavaTimePlugin ؟

الانتظار مع هذا حتى يتم الاعتناء بعلاقاتي العامة الأخرى ... إنه كثير جدًا في نفس الوقت.