Jdbi: دعم اعتراض الاستعلام

تم إنشاؤها على ٢٨ أبريل ٢٠١٦ · 27تعليقات · مصدر: jdbi/jdbi

ملاحظة: _ هذا نص منسوخ ولصق من مناقشة سابقة حول دعم اعتراض الاستعلام في العدد # 134_

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

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

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

// Here an interface that could be provided by JDBI core module.
public interface QueryInterceptor {
  // ExecutableMethod could be a wrapper to the java.lang.reflect.Method and the DAO implementation
  // Another approach to this method would be store the arguments and the query into the ExecutableMethod too...
  Object interceptQuery( ExecutableMethod daoMethod, String query, Object[] args );
}

// at some place on your code, you can attach the query interceptor into the Handler
handler.attachQueryInterceptor( new MyQueryInterceptor() );

// Here a valid implementation that does nothing but call the query
public class MyQueryInterceptor {

  public Object interceptQuery( ExecutableMethod daoMethod, String query, Object[] args ) {
    return daoMethod.invoke( args );
  }
}

// Developers whom intend to cache their queries could create their own algorithm
// Bellow a non-thread-safe sample code just to make my point
public class CachedQueries {

  final Map<CacheEntry, List<Object> cachedData = new HashMap<>();

  public Object interceptQuery( ExecutableMethod daoMethod, String query, Object[] args ) {
    final CacheEntry entry = new CacheEntry( query, args );

    Object resultObject = cachedData.get( entry );
    if ( resultObject == null ) {
      resultObject = daoMethod.invoke( args );
      cachedData.put( entry, resultObject );
    }

    return resultObject;
  }
}

// represents a cached entry
class CacheEntry {
  final String query;
  final Object[] args;

  // Implement here a constructor
  // Implement here a valid equals and hashCode methods
}

بالطبع ، هناك مجال كبير لتحسين تصميمي المقترح ، لكني أريد فقط توضيح نقطة: هل هو بسيط بما يكفي ليتم تضمينه في JDBI؟

يعتبر

feature

مصدر

miere

التعليق الأكثر فائدة

تم فتح هذه القضية لفترة من الوقت. كانت المحادثة واسعة النطاق ، لكنني أعتقد أننا استوفينا الحاجة الأساسية في هذه المرحلة.

أنا أغلق هذه التذكرة. إذا كان هناك أي مجال آخر تريد استكشافه ، فلنناقشه في قضية منفصلة.

شكرا جميعا على المناقشة الرائعة وردود الفعل.

qualidafial في ٢٧ مارس ٢٠١٧

👍2

ال 27 كومينتر

@ miere أعتقد أن هذا يمكن أن يكون عمليًا. خاصة مع واجهة برمجة تطبيقات الإضافات الجديدة ، يسعدنا دعم المشاريع (مثل ذاكرة التخزين المؤقت) الموجودة خارج النواة. إذا أصبحت طبقة التخزين المؤقت مستقرة وشائعة بدرجة كافية ، فيمكننا عندئذٍ التفكير في الترويج لها في البنية الأساسية.

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

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

stevenschlansker في ٢٨ أبريل ٢٠١٦

تضمين التغريدة
تبدو وكأنها خطة بالنسبة لي. على الرغم من أنني لست متأكدًا تمامًا مما إذا كنت على دراية بـ Query API.
هل تمانع في إرسال رابط التوثيق ، أو اختبار الوحدة ، الذي يمكنني التعرف عليه أكثر؟
ربما ، أنا فقط لا أتذكر ما يعنيه المصطلح في JDBI.

miere في ٢٨ أبريل ٢٠١٦

stevenschlansker لقد أزلت تعليقي من الإصدار القديم. يمكننا المتابعة من هنا ... ؛)

أعتقد أنه يشار إليه باسم "Fluent API" في مكان آخر - إنه المثال الأول على http://jdbi.org/
لطيف. شكرا!

لذا ، هل تعتقد أن أفضل طريقة هي استخدام Fluent API؟
هل يمكنك ، من فضلك ، تقديم مثال على ما يدور في ذهنك؟

miere في ٢٨ أبريل ٢٠١٦

miere تمامًا مثل فكرتك الأصلية ، باستثناء أنه بدلاً من البناء فوق طرق SqlObject ، قم بالاعتراض على مستوى واجهة برمجة التطبيقات بطلاقة / استعلام أقل. ثم يمكن لأي شخص يستخدم أيًا من API الاستفادة من التخزين المؤقت الخاص بك.

stevenschlansker في ١٠ مايو ٢٠١٦

آسف على إجابتي المتأخرة ، stevenschlansker

خاصة مع واجهة برمجة تطبيقات الإضافات الجديدة ، يسعدنا دعم المشاريع (مثل ذاكرة التخزين المؤقت) الموجودة خارج النواة.

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

miere في ١٤ يونيو ٢٠١٦

أنا أيضا أحب فكرة QueryInterceptor.

هل يمكن تنفيذ الحل بطريقة مشابهة لـ StatementCustomizers حيث نقوم بتحديث SQLStatement.internalExecute (QueryResultsMunger) للاتصال بـ QueryInterceptor المسجل مباشرة بعد إعادة كتابة SQL ولكن قبل إنشاء PreparedStatement؟

يجب أن تتغير واجهة QueryInterceptor لتتلقى فقط BaseStatement و / أو StatementContext أو الفئات المشتقة ثم تحديد نوع الإرجاع الذي يمكن استخدامه لتخطي رمز PreparedStatement. يعد نوع الإرجاع أكثر تعقيدًا لأننا ما زلنا نريد QueryResultsMunger لإغراق النتائج.

ما رأيك؟ هل هناك طريقة أفضل؟

chscorpio في ١ يوليو ٢٠١٦

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

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

stevenschlansker في ٦ يوليو ٢٠١٦

سعيد بسماعك ياstevenschlansker!

لا تقلق يا صاح ... سألقي نظرة عميقة على JodaTimePlugin و GuavaPlugin للحصول على بعض الإلهام. أعلم مدى صعوبة إنشاء مجتمع والمساهمة في برنامج OpenSource الذي لديه وظائف يومية ... في الأسبوعين المقبلين ، سأطلق الإصدار المستقر التالي من _kikaha_ ، وبعد ذلك سأكون سعيدًا بمساعدتكم يا رفاق في الاستعلام دعم المعترض. ؛)

miere في ٧ يوليو ٢٠١٦

رائع ، أتطلع إليه!

stevenschlansker في ٧ يوليو ٢٠١٦

مرحبًا ، chscorpio ، stevenschlansker لقد عدت ومستعد للمساعدة!

قبل البدء في كتابة الأسطر الأولى من التعليمات البرمجية بخصوص هذه المشكلة ، قضيت بعض الوقت للتعرف على Jdbi3 API. للوهلة الأولى: إنه مستقر ويبدو متسقًا عن نسخته السابقة. مبروك!

ومع ذلك ، ألقيت أيضًا نظرة عميقة على SqlStatement.internalExecute ، وكيف يعمل وكيف يعمل StatementCustomizers أيضًا. بعد قراءة الكود SqlStatement::internalExecute أثيرت بعض الشكوك في ذهني وأود التحدث مع الرجال حول هذه الأطروحات قليلاً.

قصة طويلة قصيرة:

كيف يمكنني التعامل مع تنفيذ QueryInterceptor متعدد لكل استعلام؟ سلسلة المسؤولية؟
كيف يمكنني التمييز بين طلب البحث الذي قد يكون مرشحًا ليتم تخزينه مؤقتًا واستعلامًا آخر لن يكون كذلك ، بمجرد عدم وجود بيانات وصفية مرتبطة بالبيان الحالي؟

TL ؛ الدكتور؛

لا أعرف ما هو رأيكم يا رفاق ، لكن قبل اقتراحكم ، كان لدي شيء مثل تطبيق الفلتر من Servlet API لـ Jdbi. كنت أتساءل عن إنشاء فصل دراسي حيث يمكن إخطاري بتنفيذ أي استعلام.

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

سيحتوي الكائن الأول على البيانات الوصفية ذات الصلة التي يمكنني تحليلها تحت المعترض - دعنا نسميها ExecutionContext في الوقت الحالي
والثاني سيكون البيان نفسه

كما كنت أفكر في:

سيكون ExecutionContext فارغًا إذا استخدم المستخدم Fluent / Query API بدلاً من SQLObject
وبدلاً من ذلك ، سيجعل SQLObject من QueryInterceptor يتلقى ExecutionContext والذي يمكن للمطورين استرداد التعليقات التوضيحية لأي بيانات تعريف أخرى ذات صلة من الطريقة التي تم إنشاؤها هذا البيان
الوسيطة الثانية ستستخدم نمط سلسلة المسؤولية ، إذا كان من المتوقع أن تسمح للمطورين بالحصول على أكثر من QueryInterceptor واحد لكل تنفيذ

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

إذا كنت قادرًا على إضافة تعليق توضيحي على طريقة من كائن SQL الخاص بي ، فسأكون قادرًا على تحديد الطرق التي سأقوم بتخزينها مؤقتًا (أو لا) من خلال المعترض.

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

هتافات! \ س

miere في ١٦ أغسطس ٢٠١٦

مرحبًا Miere ،

لقد فكرت في هذا الأمر أيضًا في الأشهر الفاصلة. أنا فعلا
العودة إلى التفكير في أن هذا سيكون شيئًا أنظف
سلك مع كائنات SQL بدلاً من واجهة برمجة التطبيقات (API) بطلاقة.

كجزء من العمل على جعل @Transaction يعمل على أي أسلوب كائن SQL (
https://github.com/jdbi/jdbi/pull/411) ، قدمنا ملف
SqlMethodDecoratingAnnotation التعليقات التوضيحية الوصفية (جنبًا إلى جنب مع
SqlMethodAnnotation). قد يقوم المصممون بإضافة سلوك أسلوب SQL أو استبداله.
في حالة Transaction ، فإنه يفتح فقط معاملة حول الطريقة
يتصل.

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

للتخزين المؤقت ، يمكنك تحديد تعليق توضيحي مثل Cache (ربما
مع التعليقات التكميلية الأخرى مثل CacheKey للوسيطات).

أعتقد أن تنفيذ ذاكرة التخزين المؤقت الخاصة بالجوافة سيكون جيدًا
دعم ذاكرة التخزين المؤقت للبدء بها. لدينا بالفعل قطعة أثرية jdbi3- جوافة
سيكون مكانًا جيدًا للاحتفاظ به.

دعنا نفتح مشكلة على Github ويمكننا مناقشتها أكثر هناك.

qualidafial في ١٦ أغسطس ٢٠١٦

أنت تتحدث عن مشكلة على GitHub بالفعل ؛)

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

أعتقد أن فكرتك عن واجهة برمجة تطبيقات تشبه عامل التصفية مع سياق وبيان تم تسليمها إليها قد تكون منطقية. ما الذي تحتاجه ExecutionContext الذي ليس موجودًا بالفعل في StatementContext ؟ هل هما نفس الشيء أم يجب أن يكونا مختلفين؟

stevenschlansker في ١٦ أغسطس ٢٠١٦

أنت تتحدث عن مشكلة على GitHub بالفعل ؛)

هيه. ظننت أنني كنت أرد على القائمة البريدية .. مخروط من العار

qualidafial في ١٦ أغسطس ٢٠١٦

😄1

هيه. ظننت أنني كنت أرد على القائمة البريدية .. مخروط من العار

ههههههههه ...

stevenschlansker لقد نسيت أن أفكر في StatementContext. إذا كان بإمكاننا الوصول إلى البيانات الوصفية الموجودة في كائن SQL ، فيمكننا استخدامها. ولكن ، ألقى نظرة عميقة على اقتراح

كجزء من العمل على جعل Transaction يعمل على أي أسلوب كائن SQL (
411) ، قدمنا أ
SqlMethodDecoratingAnnotation التعليقات التوضيحية الوصفية (جنبًا إلى جنب مع
SqlMethodAnnotation). قد يقوم المصممون بإضافة سلوك أسلوب SQL أو استبداله.
في حالة Transaction ، فإنه يفتح فقط معاملة حول الطريقة
يتصل.

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

لذا ، فكروا الآن أن الأمر متروك لكم يا رفاق: كلا النهجين جيد جدًا بالنسبة لي. يتميز أسلوب QueryAPI بأنه نقطة مركزية للصيانة ولكن يبدو اقتراح qualidafial أكثر نظافة. أيضًا ، إذا كان SqlMethodDecoratingAnnotation هو اختيارك ، أعتقد أن لدينا بالفعل دعم Query Interceptor (ولكن باسم آخر: P) ، وبالتالي سيتم إغلاق هذه المشكلة.

miere في ١٧ أغسطس ٢٠١٦

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

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

qualidafial في ١٧ أغسطس ٢٠١٦

تم فتح # 455 كخطوة أولى لتمكين ذلك.

qualidafial في ٢١ أغسطس ٢٠١٦

مرحبًا يا شباب ، لقد عدت! آسف لأني تركت هذه القضية بمفردها لفترة ...

أعتقد أن لدينا بالفعل دعم Query Interceptor (ولكن باسم آخر: P)

كان الهدف الأصلي من هذه المشكلة هو توفير طريقة لاعتراض الاستعلامات - أو أساليب كائنات SQL. منذ أن تم دمج PR # 455 ، تمكنت من إنشاء طرق تزيين والاعتراض. عملت بشكل مثالي على كل من إصدارات JDBI3 (alpha1 و alpha2).

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

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

يمكن العثور على رمز مصدر دعم ذاكرة التخزين المؤقت هنا . خلاصة القول ، تحتوي هذه الحزمة على Decorator يبحث عن CacheMechanism s المتاحة في classpath - عبر SPI. تحتوي هذه الحزمة أيضًا على تعليق توضيحي يمكن وضعه على طرق كائنات SQL للإشارة إلى أن نتيجتها يجب تخزينها مؤقتًا لاستخدامها لاحقًا. هنا يمكنك مشاهدة تطبيق CacheMechanism البسيط للغاية الذي يحفظ نتيجة الطريقة في HashMap .

هنا يمكنك مشاهدة اختبار التكامل مع آلية التخزين المؤقت قيد التنفيذ. سيتم تنفيذ الاستعلام SELECT NOW() ، المرجع بواسطة Queries.returnTheSolutionForTheUniverseAndEverythingElse (: P) ، مرة واحدة فقط.

من فضلك ، أرسل لي ملاحظات ... حسنًا؟ إذا كنت تعتقد أن هذا سيكون مفيدًا لـ JDBI3 ، فسأقوم بدور العلاقات العامة غدًا مع هذا التنفيذ الأساسي. أود أيضًا إنشاء CacheMechanism للجوافة في وحدة jdbi3-guava الحالية.

miere في ٩ نوفمبر ٢٠١٦

مرحبًا Miere ، تبدو هذه بداية جيدة!

أنا أدافع حاليًا عن تغيير في النواة من المحتمل أن يغير واجهة v3 Handler ، مما سيجبرك على القيام ببعض إعادة العمل. آمل أن تكون المقايضة جديرة بالجهود المبذولة على الرغم من أنها ستمنح المستخدمين ومؤلفي المكتبة القدرة على توسيع JDBI بتكوينهم الخاص وجعله قابلاً للاستخدام من قبل أي شخص. يمكنني رؤية هذا [تحرير: نسيت إنهاء الجملة] يمكنني أن أرى أن هذه طريقة مفيدة لتسجيل آليات ذاكرة التخزين المؤقت على سبيل المثال.

أنا متردد في اعتماد ~~هذا~~ التخزين المؤقت في JDBI المناسب في هذه المرحلة.

أولاً ، يحتاج هذا إلى وقت للنضج ، وإثبات نفسه للعمل بشكل جيد لمجموعة متنوعة من المستخدمين والبيئات. إذا أضفناه ، فربما أبقي تنفيذ ذاكرة التخزين المؤقت للجوافة منفصلاً عن jdbi3-guava .

ثانيًا ، يعد إدخال التخزين المؤقت نوعًا من الانطلاق الفلسفي (كما أراه) للمشروع. يعمل JDBI دائمًا كمترجم بين وقت تشغيل java وقاعدة البيانات - مجرد ترجمة الأوامر والطلبات من تنسيق إلى آخر دون تغيير أي دلالات. ستؤدي إضافة التخزين المؤقت إلى جعل JDBI يعمل كوكيل (كما يفعل Hibernate) بدلاً من كونه مترجمًا.

أنا شخصياً أرى ذاكرة التخزين المؤقت للجلسة على أنها أكبر نقطة ضعف في Hibernate - بمجرد فتح هذا الباب ، يصبح من السهل جدًا على المكتبة أن تبدأ في التعامل معك ، محاولًا أن تكون ذكيًا نيابةً عنك بدلاً من مجرد فعل ما أخبرتها به. تجنب JDBI الوقوع في هذا الفخ حتى الآن ، وأنا متردد في البدء في السير بالقرب منه الآن.

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

qualidafial في ٩ نوفمبر ٢٠١٦

miere يرجى إلقاء نظرة على أحدث كود في فرع jdbi3 .

يوفر JDBI 3 الآن آلية تكوين ، ويمكنك إضافة بيانات التكوين العشوائية الخاصة بك عن طريق تنفيذ JdbiConfig :

public class Caching implements JdbiConfig<Caching> {
  public Caching() {}

  private Caching(Caching that) {
    this.cacheMechanism = that.cacheMechanism;
  }

  private CacheMechanism cacheMechanism;

  public CacheMechanism getCacheMechanism() {
    return cacheMechanism;
  }

  public void setCacheMechanism(CacheMechanism cacheMechanism) {
    this.cacheMechanism = cacheMechanism;
  }

  // and any other universal caching configuration

  public Caching createCopy() {
    return new Caching(this);
  }
}

بعد ذلك ، في معالج أسلوب ذاكرة التخزين المؤقت:

<strong i="13">@RequiredArgsConstructor</strong>
public class CachedMethodHandler implements Handler {

  final Handler base;

  <strong i="14">@Override</strong>
  public Object invoke(Object target,
                       Method method,
                       Object[] args,
                       HandleSupplier handle) throws Exception {
    CacheMechanism cacheMechanism = handle.getConfig(Caching.class).getCacheMechanism();

    final SQLObjectMethod sqlObjectMethod = new SQLObjectMethod(method, args);
    Object foundData = cacheMechanism.loadDataFor(sqlObjectMethod);
    if ( foundData == null ) {
      foundData = base.invoke( target, method, args, config, handle );
      cacheMechanism.storeDataFor( sqlObjectMethod, foundData );
    }
    return foundData;
  }
}

أخطط لإصدار v3 alpha آخر إلى Maven Central مع عناصر التكوين في وقت لاحق اليوم.

qualidafial في ٢٧ نوفمبر ٢٠١٦

❤1

تحسن لطيف للغاية. سوف أرسل إلى هذا الليلة.

حول تنفيذ التخزين المؤقت لـ JdbiConfig. كيف من المفترض أن أبلغ Jdbi بوجود JdbiConfig جديد؟ هل يجب علي تسجيله في تكوين البرنامج المساعد؟ أم يجب أن أقدمها كتطبيق SPI لواجهة JdbiConfig؟

miere في ٢٨ نوفمبر ٢٠١٦

سيقوم JDBI بإنشاء مثيل لكائن التكوين الخاص بك في المرة الأولى التي تطلبه فيها لهذا النوع. Jdbi و Handle و SqlStatement بتطبيق واجهة Configurable مع العديد من الطرق الملائمة للوصول إلى التكوين.

Jdbi jdbi = ...
jdbi.getConfig(Caching.class).setCacheMechanism(new LocalCacheMechanism());

qualidafial في ٢٨ نوفمبر ٢٠١٦

لم أتمكن من إطلاق سراحه الليلة الماضية - لقد فعلت ذلك منذ دقيقة واحدة فقط. يجب أن يكون متاحًا في Central كإصدار 3.0.0-alpha4 قريبًا.

qualidafial في ٢٨ نوفمبر ٢٠١٦

miere هل جربت

qualidafial في ٢٦ يناير ٢٠١٧

qualidafial شكرا على السؤال ...

في الواقع ، لم أتمكن من إعطاء فرصة لـ alpha4 كما ذكرت من قبل ... لقد كنت مشغولاً قليلاً في الأشهر القليلة الماضية. سألقي نظرة عميقة على الأمر في نهاية هذا الأسبوع ، وبعد ذلك أقدم لك تعليقًا ... حسنًا؟

يعتبر

miere في ٢٦ يناير ٢٠١٧

تنبيه ، أطلقنا الإصدار التجريبي هذا الصباح

qualidafial في ٢٦ يناير ٢٠١٧

مرحبًا qualidafial ، لقد قمت للتو بتكييف كود ذاكرة التخزين المؤقت السابق الخاص بي مع بنية 3.0.0-beta0 وقد عملت بشكل كبير!
لقد حددت أن جميع المعلومات الوصفية غير القابلة للتغيير ، مثل الطريقة ، يتم تخزينها على كائن HandleSupplier ... عمل رائع.

miere في ١٣ فبراير ٢٠١٧

أنا أغلق هذه التذكرة. إذا كان هناك أي مجال آخر تريد استكشافه ، فلنناقشه في قضية منفصلة.

شكرا جميعا على المناقشة الرائعة وردود الفعل.

qualidafial في ٢٧ مارس ٢٠١٧

👍2

هل كانت هذه الصفحة مفيدة؟

0 / 5 - 0 التقييمات

القضايا ذات الصلة

يتعذر على BindList العثور على المعلمة المسماة في الاستعلام ويقوم بطرح استثناء

johanneszink · 4تعليقات

إزالة الاعتماد على SLF4J

electrum · 3تعليقات

مقارنة بين "JDBI" و "Jdbi" و "Jdbi"

stevenschlansker · 4تعليقات

خريطة kotlin

buremba · 5تعليقات

كيف يتم تنفيذ البيانات المعدة؟

goxr3plus · 4تعليقات