Jdbi: دليل المطور: الترحيل من الإصدار 2 إلى الإصدار 3

ملاحظات من ترحيل مشروع صغير:

الفئات التي تمت إعادة تسميتها (ليس بهذه البساطة مثل حذف الواردات والسماح لـ IDE بإصلاحها):

• DBI -> Jdbi
• IDBI -> Jdbi
• DBIException -> JdbiException

تم استبدال المُنشئين لـ $ # Jdbi create() بطريقة المصنع $ # $ 7 $ # $.

تم استبدال ResultSetMapper بـ RowMapper $ ولم يعد الأسلوب map يحتوي على فهرس الصف. فئة باسم ResultSetMapper موجودة في Jdbi 3 ، لكنها تخدم غرضًا مختلفًا. تم استبدال @Mapper بـ @UseRowMapper . تم استبدال registerMapper() على Jdbi بـ registerRowMapper() .

تم استبدال @BindIn بـ @BindList ولم يعد يتطلب StringTemplate.

باستخدام نموذج Jdbi الافتراضي ، لا يتم اقتباس أقواس الزاوية ، مما يعني أن IntelliJ يفهم البنية بعد تكوين نموذج المعلمة ضمن أدوات -> قاعدة بيانات -> أنماط المستخدم .

لم يعد النوع الافتراضي $ # Query Map وبالتالي لا يمكن استدعاء list() عليه مباشرة. اتصل بـ mapToMap() قبل الاتصال بـ list() .

TransactionStatus لم يعد موجودًا.

TransactionConsumer.useTransaction() يأخذ فقط Handle الآن ، لذلك يجب إزالة الوسيطة TransactionStatus عند استخدام هذا مع useTransaction() على Jdbi أو Handle .

TransactionCallback.inTransaction() يأخذ فقط Handle الآن ، لذلك يجب إزالة الوسيطة TransactionStatus عند استخدام هذا مع inTransaction() على Jdbi أو Handle .

CallbackFailedException لم يعد موجودًا. يمكن الآن للواجهات الوظيفية المختلفة مثل HandleConsumer ، HandleCallback ، TransactionalConsumer ، و TransactionalCallback ، طرح أي نوع من الاستثناءات (لكن يتم تقييد استخدام الأدوية العامة لتجنب الفحص غير الضروري معالجة الاستثناء).

لم يعد دعم كائن SQL متوفراً بشكل افتراضي. يجب أن يتم تسجيله في كل مثيل Jdbi تم إنشاؤه.

كان معمل ترحيل IntelliJ's Migrate Refactor مفيدًا لبدء الترحيل.

شكرا electrum لوضع هذا معا! ستكون هذه مساعدة كبيرة

بعض الملاحظات الإضافية من مراجعة العرض التقديمي الخاص بي:

• تم تغيير اسم المصنوعات إلى org.jdbi: jdbi -> org. jdbi: jdbi3 ،: jdbi3-sqlobject ،: jdbi3-guava ، إلخ
• تم تغيير الحزمة الأساسية: org.skife.jdbi.v2 -> org.jdbi.v3. هذا يعني أنه يمكن أن يتواجد الإصداران 2 و 3 في مشروع أثناء الترحيل
• تمت إعادة تسميته: GetHandle -> SqlObject
• v3 تستخدم مصانع وسيطة ورسم الخرائط java.lang.reflect.Type ، بينما تستخدم v2 java.lang.Class . هذا يعني أن الإصدار 3 قادر على التعامل مع تواقيع النوع العام المعقدة التي لم يستطع الإصدار 2.
• v3 مصانع الوسيطات ورسم الخرائط والواجهات الوظيفية أحادية الأسلوب التي ترجع قيمة اختيارية. v2 له طريقتان Accepts () و build () منفصلتان.
• يجب أن تكون أنواع كائنات SQL في الإصدار 3 واجهات عامة فقط - بدون فئات. يجب أيضًا أن تكون أنواع إرجاع الطريقة عامة. ويرجع ذلك إلى تبديل تنفيذ كائن SQL من CGLIB إلى java.lang.reflect.Proxy ، الذي يدعم الواجهات فقط.
• يمكن جعل التعليقات التوضيحية @Bind على معلمات أسلوب كائن SQL اختيارية ، عن طريق تجميع التعليمات البرمجية الخاصة بك مع تمكين علامة -parameters .
• لا تعمل كائنات SQL عند الطلب بشكل جيد مع الأساليب التي تُرجع العناصر التكرارية. تقوم الكائنات عند الطلب بإغلاق المقبض بدقة بعد كل استدعاء للطريقة ، ولم يعد "إبقاء الباب مفتوحًا" حتى تنتهي من استهلاك العناصر المكررة كما فعلت في الإصدار 2. هذا يمنع مصدرًا رئيسيًا لتسريبات الاتصال.
• لم تعد كائنات SQL قابلة للإغلاق - فهي إما عند الطلب ، أو أن دورة حياتها مرتبطة بدورة حياة المقبض الذي تم إرفاقها به.
• تمت إزالة واجهة StatementLocator من النواة. تتوقع جميع البيانات الأساسية تلقي SQL الفعلي الآن. مفهوم مشابه ، تمت إضافة SqlLocator ولكن فقط في مجال كائنات SQL.

واحد آخر: StatementRewriter تم إعادة تشكيله ليصبح TemplateEngine و SqlParser .

من المهم جدًا أن تضيف إلى القائمة سلوك التحديد. انطلق من هذا:

List<Map<String, Object>> rs = h.select("select id, name from something");

الى هذا:

List<Map<String, Object>> rs = h.select("select id, name from something").mapToMap().list();

أتمنى أن القوة الإضافية والمرونة والأمان لـ v3 لا تأتي مع ثمن الإسهاب.

مرحبًا javajosh ، لم نعتبر هذا الشخص بالذات سيئًا للغاية لأننا نحاول تثبيط التعيين إلى Map كائنات. إذا لم يكن هناك شيء آخر ، فإن القواعد المتعلقة بحساسية حالة الأحرف للمفاتيح مربكة. هل هناك سبب لضرورة إصدار Map بدلاً من إنشاء النوع المحدد الخاص بك؟ أنا شخصياً سوف أكتب دائمًا فئات نتائج صغيرة (باستخدام مُنشئ / حقل / محددات الخرائط والمجلدات) وأتجنب دائمًا استخدام Map . هل لديك حالة استخدام حيث تكون مريحة للغاية؟

مرحبًا stevenschlansker - أنا أتناولها من منظور "تجربة المطورين الأولى". الكود أعلاه مأخوذ من برنامج تعليمي v2 الخاص بك ، والذي أعتقد أنه بسيط بشكل مثير للإعجاب. وبالفعل ، مع لغة مستضافة من JVM مثل Groovy ، والتي تحتوي على خريطة تشبه جافا سكريبت مضمنة ، فمن المحتمل أن ترى نتيجة غير مكتوبة في كثير من الأحيان.

javajosh ما رأيك في https://github.com/jdbi/jdbi/pull/925 ؟

stevenschlansker هل تقصد # 928؟

تضمين التغريدة لكنها لا تزال مطولة أكثر من الإصدار 2. :) هذا بالإضافة إلى الإسهاب الأكبر في المخضرم ، وما إلى ذلك ، فأنا لا أريد أن أرى JDBI يسلك طريق JUnit الذي كافح لجعل الناس يتبنون الإصدار 4 لأنه يحتوي على بعض الميزات الرائعة ، ولكنه كان أكثر تعقيدًا بكثير من v3 و v3 كانت "جيدة بما فيه الكفاية". لدي نفس الشعور تجاه بناء جملة "withHandle" (على الرغم من أنني أفهم غريزتك للتخلص من جميع المقابض المتدلية).

javajosh لا يزال لديك Jdbi.open() إذا كنت تريد قدرًا أكبر من التحكم ، على الرغم من أننا نوصيك باستخدامه داخل مجموعة تجربة الموارد من أجل الأمان.

بدء العمل على مستندات الترحيل من الإصدار 2 إلى الإصدار 3.

javajosh العودة إلى الطريقة ResultBearing.list() التي تُرجع List<Map<String,Object>> : لست متأكدًا من أن إضافة هذه كانت فكرة جيدة ، خاصة في وقت متأخر من دورة الإصدار.

أنا متعاطف مع مخاوفك بشأن الإسهاب ، لكن هذا الإسهاب يخدم الغرض من توضيح نية المطور:

handle.createQuery(sql)
    .mapToMap()
    .list()

أوضح للقارئ من:

handle.createQuery(sql)
    .list()

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

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