Jdbi: @CreateSqlObject को कम भ्रमित करने वाला बनाएं।

इसकी रिपोर्ट करने के लिए धन्यवाद। मुझे संदेह है कि हम यहां तकनीकी रूप से ब्रेकिंग परिवर्तन के साथ समाप्त हो जाएंगे, लेकिन मुझे लगता है कि मौजूदा व्यवहार इतना खराब है कि हम 3.x रिलीज चक्र में तकनीकी रूप से ब्रेकिंग बदलाव करते हैं। कृपया इस मुद्दे को फ़्लैग करें यदि आप मौजूदा व्यवहार पर निर्भर हैं या संभावित रूप से एक छोटे से ब्रेकिंग परिवर्तन को यहां भेजने से असहमत हैं।

केवल संदर्भ के लिए _why_ @CreateSqlObject ऑन-डिमांड के साथ अच्छा नहीं खेलता है:

• ऑन-डिमांड एक कोर-लेवल एब्स्ट्रैक्शन है, जिसे प्रॉक्सी का उपयोग करके लागू किया जाता है। जब आप ऑन-डिमांड प्रॉक्सी पर कोई विधि कॉल करते हैं, तो एक वास्तविक SQL ऑब्जेक्ट बनाया जाता है और विधि कॉल को वास्तविक SQL ऑब्जेक्ट को प्रत्यायोजित किया जाता है। वास्तविक उदाहरण का समर्थन करने वाला हैंडल प्रतिनिधि विधि कॉल रिटर्न के बाद बंद हो जाता है।
• @CreateSqlObject को मूल SQL ऑब्जेक्ट के बैकिंग हैंडल के साथ handle.attach(sqlObjectType) का उपयोग करके कार्यान्वित किया जाता है।

इस प्रकार, बनाए गए SQL ऑब्जेक्ट के लिए बैकिंग हैंडल SQL ऑब्जेक्ट को वापस किए जाने से पहले बंद कर दिया जाता है।

उपरोक्त में से कोई भी पत्थर में सेट नहीं है - यह अभी कैसे लागू किया गया है।

मुझे विश्वास नहीं है कि इसे ठीक करने के लिए हमें संगतता को तोड़ना होगा।

क्षमा करें, मुझे वास्तव में समझ नहीं आया... onDemand और CreateSqlObject में वास्तव में क्या समस्या है? मुझे इससे कभी कोई समस्या नहीं हुई, और @qualidafial की व्याख्या के बारे में कुछ ऐसा है जो मेरे दिमाग को झुका रहा है ...

fooProxy.usecase पर कॉल के लिए एक कनेक्शन प्राप्त किया जाता है। Foo.usecase createSqlObject मेथड बार को कॉल करता है, जो इसे करंट ( usecase के) हैंडल से अटैच करने के बाद एक नया बार देता है। usecase वापस आने पर usecase का हैंडल बंद हो जाता है। जब तक आप बार लौटाए गए बार के साथ एसिंक्रोनस कुछ भी नहीं कर रहे हैं, तो बार का हैंडल बहुत जल्दी कैसे समाप्त हो सकता है? bar का जीवनचक्र और उपयोग Foo.usecase के मुख्य भाग तक सीमित है, जैसा कि हैंडल है...

मैं JDBI के आंतरिक लोगों से बात नहीं कर सकता, हालाँकि मैं उत्पादन में हमारे द्वारा देखे गए व्यवहार पर टिप्पणी कर सकता हूँ।

मूल रूप से, हमारे निचले वातावरण में चीजें ठीक थीं। लेकिन उत्पादन में बढ़े हुए भार के साथ, हम लगातार देखेंगे कि SQL कथन उचित डेटाबेस नोड के विरुद्ध निष्पादित नहीं होते हैं। उदाहरण के लिए, केवल पढ़ने के लिए चयन मास्टर नोड को हिट करेगा, और एक सम्मिलित एक पठन प्रतिकृति को हिट करेगा। इसके अलावा, हमें कनेक्शन बंद त्रुटियां मिलेंगी जहां यह एक ऑपरेशन के बीच में थी।

अनिवार्य रूप से, ऐसा लगता है कि @CreateSqlObject ने थ्रेड सुरक्षा समस्या बनाई - जहां प्रतिस्पर्धात्मक अनुरोधों द्वारा केवल-पढ़ने वाले ध्वज को बदला जा रहा था।

समस्या को "समाधान" करने के लिए - हमने @CreateSqlObject के सभी उपयोग को हटा दिया, और कुछ इस तरह से समाप्त हुआ:

• class FooDao
• class BarDao
• class CombinedDao extends FooDao, BarDao

और फिर हम jdbi.onDemand(CombinedDao) और केवल उसी के माध्यम से पहुंच का उपयोग करते हैं।
उस पैटर्न पर स्विच करना, जबकि उतना सुंदर नहीं था, उत्पादन में उपरोक्त सभी त्रुटियों से छुटकारा मिला।

केवल जानकारी के लिए, मैं JDBI 2 पर वापस जाने के बारे में सोच रहा हूँ क्योंकि मेरे सभी कोड इस समय अमूर्त कक्षाओं के साथ ऑन डिमांड का उपयोग करते हैं, और मैं यह नहीं समझ सकता कि किस तरह से मैं खुश रहूँगा!

मेरे पास सेवा इंटरफेस है, जिसमें तर्क युक्त अमूर्त कार्यान्वयन वर्ग हैं, लेकिन कोई एसक्यूएल नहीं है, लेनदेन के रूप में एनोटेट किए गए तरीकों के साथ, CreateSqlObject का उपयोग करके डीएओ कक्षाओं तक पहुंच प्रदान करने के लिए जो पूरी तरह से एसक्यूएल हैं। एक सरलीकृत उदाहरण:

इंटरफेस

public interface AccountService {
    void addAccount(Account account, User user);
}  

कार्यान्वयन

public abstract class AccountServiceJdbi implements AccountService {

    <strong i="11">@Override</strong>  
    <strong i="12">@Transaction</strong>  
    public final void addAccount(@BindBean() Account account, User user) {
        long accountId =  accountDao().insertAccount(account);
        accountDao().linkAccountToOwner(accountId, user.getId());
    }

    <strong i="13">@CreateSqlObject</strong>
    abstract AccountDao accountDao();
}

(आप दाओ की कल्पना कर सकते हैं)

यह कई डीएओ विधियों पर लेनदेन की अनुमति देते हुए तर्क और डेटा एक्सेस का वास्तव में अच्छा अलगाव देता है। डीएओ इंटरफेस को लागू करके सेवा के लिए यूनिट परीक्षण लिखना और समझना आसान है।

मैंने जेडीबीआई 3 में ऐसा ही करने की कोशिश की है, लेकिन मुझे लगता है कि इसका मतलब है कि मेरी सेवा वर्ग के कार्यान्वयन में तर्क वाले लोगों के लिए डिफ़ॉल्ट विधियों के साथ एक इंटरफ़ेस होना चाहिए। डिफ़ॉल्ट विधियों को अंतिम नहीं बनाया जा सकता है, इसलिए कोड बस उतना संक्षिप्त नहीं लगता है, और मुझे इस पर कम नियंत्रण देता है कि मेरी कक्षा का उपयोग कैसे किया जा सकता है।

क्या कोई तरीका है जिससे मैं अपने कोड को अंतिम लेन-देन के तरीकों के लिए JDBI 3 में संरचित कर सकता हूं?

आप सही हैं कि इंटरफ़ेस विधि को अंतिम रूप में परिभाषित करने का कोई तरीका नहीं है।

आप _can_ हालांकि @SqlQuery , @SqlUpdate , आदि के बराबर अपने स्वयं के SQL विधि एनोटेशन को परिभाषित करते हैं, और उस एनोटेशन के साथ विधियों के लिए एक स्थिर कार्यान्वयन प्रदान करते हैं।

आप _can_ हालांकि @SqlQuery , @SqlUpdate , आदि के बराबर अपने स्वयं के SQL विधि एनोटेशन को परिभाषित करते हैं, और उस एनोटेशन के साथ विधियों के लिए एक स्थिर कार्यान्वयन प्रदान करते हैं।

उत्तर के लिए धन्यवाद - मैं काफी अनुसरण नहीं करता कि इससे मुझे कैसे मदद मिलती है। एकाधिक डीएओ में प्रश्न पूछने का अनुशंसित तरीका क्या है, लेकिन उन्हें एक ही लेनदेन में निष्पादित करें?

एकाधिक डीएओ में प्रश्न पूछने का तरीका, लेकिन उन्हें उसी लेनदेन में निष्पादित करें?

व्यक्तिगत रूप से मैं कुछ इस तरह का उपयोग करता हूं

interface Dao1 {
  @SqlQuery("...")
  void query1();
}

interface Dao2 {
  @SqlQuery("...")
  void query2();
}

interface JdbiServiceImpl extends Service {
  <strong i="8">@CreateSqlObject</strong>
  Dao1 dao1();
  <strong i="9">@CreateSqlObject</strong>
  Dao2 dao2();

  <strong i="10">@Transaction</strong>
  <strong i="11">@Override</strong>
  void businessCase() {
    dao1().query1();
    dao2().query2();
  }
}

Service service = handle.attach(JdbiServiceImpl.class);
service.businessCase();

इस तरह मेरे लिए बहुत अच्छा काम करता है। @CreateSqlObject मूल रूप से गेटर/सेटर द्वारा वसंत की निर्भरता इंजेक्शन की तरह है। मैं अपने वसंत संदर्भ पर सेम के रूप में ऑन डिमांड इंस्टेंस डालता हूं, इसलिए यह नियमित सेवाओं की तरह काम करता है, कॉलर्स को जेडीबीआई या कार्यान्वयन इंटरफ़ेस के बारे में जानने की आवश्यकता नहीं है।

आप जो एंटी-पैटर्न-दिखने वाली StockReductionCase चीज़ देखते हैं, वह CreateSqlObject के साथ नेस्टेड jdbi "डिपेंडेंसी इंजेक्शन" का एक उदाहरण है। सेवा कार्यान्वयन की तरह, इसके अंदर इसकी अपनी निर्भरता है। यह मूल रूप से अपने आप में एक सेवा है, मैं इसे सेवा के बजाय केवल केस (कई स्थानों में आवश्यक) सेवाओं (शीर्ष-स्तरीय गैर-पुन: प्रयोज्य तर्क) और प्रश्नों को या तो डालकर चक्रीय निर्भरता से बचने के लिए कहता हूं।

मैंने @CreateSqlObject के साथ लेनदेन को सही ढंग से दायरे में लाने की सफलता की मिश्रित रिपोर्टें सुनी हैं, खासकर जब onDemand() के साथ संयुक्त।

एक ही लेन-देन में एकाधिक SQL ऑब्जेक्ट निष्पादित करने का सबसे सुरक्षित तरीका Handle.inTransaction() या Jdbi.inTransaction() के माध्यम से लेनदेन चलाना है। कॉलबैक के अंदर, Handle.attach() के माध्यम से बनाया गया कोई भी डीएओ हैंडल के लेनदेन का हिस्सा होगा:

jdbi.useTransaction(handle -> {
  Dao1 dao1 = handle.attach(Dao1.class);
  Dao2 dao2 = handle.attach(Dao2.class);

  dao1.doStuff();
  dao2.doMoreStuff();
});

उत्तरों के लिए धन्यवाद
@qualidafial ऐसा लगता है कि मुझे जिस तरह से जाना होगा, लेकिन इससे सेवा वर्ग के लिए यूनिट परीक्षण लिखना मुश्किल हो जाता है। चूंकि यह डाओस को तुरंत चालू करता है, इसलिए मैं यूनिट परीक्षणों के लिए नकली डाओस को स्थानापन्न नहीं कर सकता।

@TheRealMarnes भी धन्यवाद - यह वही दिखता है जो मैंने कोशिश की थी, मुझे डिफ़ॉल्ट विधियों का उपयोग करना पसंद नहीं है क्योंकि उन्हें ओवरराइड किया जा सकता है।

@qualidafial मैं आपके साथ पुष्टि करना चाहूंगा कि हम jdbi के @Transaction एनोटेशन का उपयोग सेवा विधियों पर नहीं कर सकते हैं जो कई dao विधियों को लागू कर रहे हैं?

यदि यह धारणा सही है, तो आधिकारिक दस्तावेज के एक भाग के रूप में ठीक से प्रलेखित किए बिना यह व्यवहार बहुत खतरनाक है। बड़ी संख्या में डेवलपर्स के पास स्प्रिंग स्टैक का अनुभव है और कई डीएओ में लेनदेन का समर्थन करने के लिए @Transactional एनोटेशन का उपयोग करना बहुत ही मानक तरीका है।

@svlada @Transaction एनोटेशन _only_ SQL ऑब्जेक्ट्स के तरीकों पर काम करता है। जब आप "सेवा विधियों" कहते हैं तो मुझे लगता है कि आप जेडीबीआई के प्रभाव से बाहर किसी ऑब्जेक्ट पर एनोटेशन का उपयोग कर रहे हैं, उदाहरण के लिए इंजेक्शन वर्ग।

हमारे परीक्षण सूट से एक उदाहरण:

<strong i="9">@Test</strong>
public void testInsertAndFind() {
    Foo foo = handle.attach(Foo.class);
    Something s = foo.insertAndFind(1, "Stephane");
    assertThat(s).isEqualTo(new Something(1, "Stephane"));
}

<strong i="10">@Test</strong>
public void testTransactionPropagates() {
    Foo foo = dbRule.getJdbi().open().attach(Foo.class);

    assertThatExceptionOfType(Exception.class)
        .isThrownBy(() -> foo.insertAndFail(1, "Jeff"));

    Something n = foo.createBar().findById(1);
    assertThat(n).isNull();
}

public interface Foo {
    <strong i="11">@CreateSqlObject</strong>
    Bar createBar();

    @SqlUpdate("insert into something (id, name) values (:id, :name)")
    int insert(@Bind("id") int id, @Bind("name") String name);

    <strong i="12">@Transaction</strong>
    default Something insertAndFind(int id, String name) {
        insert(id, name);
        return createBar().findById(id);
    }

    <strong i="13">@Transaction</strong>
    default Something insertAndFail(int id, String name) {
        insert(id, name);
        return createBar().explode();
    }
}

public interface Bar {
    @SqlQuery("select id, name from something where id = :id")
    Something findById(@Bind("id") int id);

    default Something explode() {
        throw new RuntimeException();
    }
}

मैं onDemand() + @CreateSqlObject के संबंध में भी स्पष्ट करना चाहता हूं:

• @CreateSqlObject डीएओ का उपयोग केवल डीएओ के अंदर के तरीकों से किया जा सकता है जिसने उन्हें बनाया - जैसा कि ऊपर के उदाहरण में है।
• fooDao.createBar().findById() पर कॉल करने से यह अपवाद होगा कि कनेक्शन बंद है।

इस पर फिर से टिप्पणी करने के लिए खेद है। क्या आपके रोड मैप में ऐसा कुछ है जो इसमें मदद करेगा?

मुझे अभी भी अमूर्त कक्षाओं में CreateSqlObject का उपयोग करने में सक्षम होने की याद आती है। इंटरफेस में सब कुछ करने के बाद भी प्रतिबंधात्मक लगता है; अक्सर मैं एक "सेवा" प्रकार की विधि को लेन-देन करना चाहता हूं, लेकिन इसका मतलब यह होगा कि मेरी सेवा कक्षाओं को भी डिफ़ॉल्ट तरीकों का उपयोग करके इंटरफेस होना चाहिए और मैं चिंताओं को अलग करने, ठोस अंतिम विधियों आदि की स्पष्टता खोना शुरू कर देता हूं।

@tamslinn जहाँ तक अमूर्त वर्गों के बजाय इंटरफेस के साथ आपकी समस्या का संबंध है, मुझे लगता है कि मैं सुरक्षित रूप से कह सकता हूं कि हम निकट भविष्य में उस निर्णय से वापस नहीं आएंगे। Jdbi3 jdk प्रॉक्सी का उपयोग करता है, जो केवल इंटरफेस का समर्थन करता है।

मुझे नहीं लगता कि cglib पर बनाया गया एक योगदान अलग मॉड्यूल या कुछ ऐसा जो इस सुविधा की पेशकश करता है, पूरी तरह से सवाल से बाहर है, लेकिन यह अभी चिंता का विषय नहीं है।

यदि sqlobject स्वयंसिद्ध आपको बुरी तरह से सूट करते हैं, तो आप हमेशा अपनी सेवाओं को नियमित कक्षाओं के रूप में पुन: सक्रिय कर सकते हैं, जो कि jdbi द्वारा नहीं बढ़ाया जाता है, बल्कि इसके बजाय धाराप्रवाह एपीआई का उपयोग करने के लिए Jdbi इंस्टेंस इंजेक्ट किया जाता है।

जहां तक ​​हमारे लेन-देन समर्थन, ऑन डिमांड, आदि के बीच व्यवहार के मूल विषय का सवाल है, उस पर काम करने के लिए अधिक से अधिक ध्यान केंद्रित किया जा रहा है, हालांकि मुझे नहीं लगता कि हमारे पास अभी तक वास्तव में ठोस योजनाएं हैं। लेकिन हम इसे प्राप्त कर रहे हैं।

अपडेट के लिए बहुत बहुत धन्यवाद। परदे के पीछे पूरी तरह से समझ में आता है।
मेरे लिए विशिष्ट सीमा जेडीबीआई कक्षाओं के बाहर लेनदेन शुरू/समाप्त करने में सक्षम नहीं है।
(जैसा कि @svlada द्वारा उल्लेख किया गया है, उच्च स्तर पर @Transactional का उपयोग करना अन्य ढांचे में काफी आम है)
मुझे वास्तव में JDBI के बारे में बाकी सब कुछ पसंद है, इसलिए मैं इसे जारी रखूंगा, हो सकता है कि मैं एक डिजाइन पैटर्न के साथ आऊं जिससे मैं अपनी सेवा कक्षाओं के लिए खुश हूं :)

इस पर फिर से टिप्पणी करने के लिए खेद है। क्या आपके रोड मैप में ऐसा कुछ है जो इसमें मदद करेगा?

कोई समस्या नहीं। यह स्पष्ट रूप से भ्रम का एक स्रोत है, और कुछ जिसे हम ठीक करना चाहते हैं - हम वास्तव में इस बार इसे ठीक करना सुनिश्चित करना चाहते हैं, क्योंकि हमने पिछली बार नहीं किया था :)

(जैसा कि @svlada द्वारा उल्लेख किया गया है, उच्च स्तर पर @Transactional का उपयोग करना अन्य ढांचे में काफी आम है)

हाँ, लेकिन जहाँ तक मैं समझता हूँ, यह सब आपके DI ढांचे (जैसे स्प्रिंग) में AOP हुक के माध्यम से किया जाता है। चूंकि JDBI आपके सभी सेवा उद्देश्यों को "रैप" नहीं करता है, इसलिए हमारे पास उन वस्तुओं के लिए AOP- जैसे समाधान प्रदान करने का कोई अवसर नहीं है जो हम स्वयं नहीं बनाते हैं। यहां तक ​​​​कि पुराने cglib कार्यान्वयन केवल @Transactional को स्वयं दास पर ही नोटिस करेगा, यह कभी भी एक अलग सेवा वर्ग पर काम नहीं करता।

यदि यह मददगार होगा, तो हम उच्च स्तर पर लेनदेन की अनुमति देने के लिए स्प्रिंग और/या गुइस एओपी बाइंडिंग जोड़ने पर विचार कर सकते हैं। यह core का हिस्सा नहीं होगा लेकिन उदाहरण के लिए spring एक्सटेंशन का हिस्सा होगा। यह कुछ ऐसा होने की संभावना नहीं है जिस पर मुख्य डेवलपर्स कूदते हैं, लेकिन एक योगदान को शामिल करने के लिए गंभीरता से विचार किया जाएगा। हो सकता है कि यह आपकी समस्या को "क्लीनर" तरीके से हल करे?

हमने अधिकतर संगतता कारणों से cglib से Proxy पर स्विच करने का निर्णय लिया - Proxy एक समर्थित jdk एपीआई है, जबकि cglib (या अधिक विशेष रूप से asm ) हर बड़ी रिलीज के साथ टूट जाता है (यह 8, 9, 11, ... को टूट गया) जो एक बड़े रखरखाव सिरदर्द में बदल जाता है।

शायद https://github.com/jdbi/jdbi/pull/1252 प्रासंगिक है?

नमस्ते,

जानकारी के लिए धन्यवाद @stevenschlansker। मैं वास्तव में अपने वर्तमान प्रोजेक्ट के लिए जेडीबीआई के साथ स्प्रिंग का उपयोग नहीं कर रहा हूं, बस तुलना के लिए उल्लेख किया गया था। मैं एओपी सामान को पूरी तरह से समझता हूं, बस इसके चारों ओर एक रास्ता खोजने की कोशिश कर रहा हूं जिसका मतलब है कि मैं कोड को विभाजित कर सकता हूं कि मैं कैसे चाहता हूं - अमूर्त वर्ग मेरे लिए काम करते थे, लेकिन यह cglib से दूर जाने के लिए पूरी तरह से समझ में आता है

मैं अब सोच रहा हूं कि जब मुझे उनकी आवश्यकता होगी तो मैं अपनी सेवा कक्षाओं का निर्माण करूंगा, इस तरह मैं उन्हें लेनदेन के अंदर बना सकता हूं।

         try (Handle handle = jdbi.open()) {
                handle.useTransaction(h -> {
                    AccountService accountService = new AccountServiceImpl(h.attach(AccountDao.class));                    
                    accountService.addAccount(a, u);
                });
          }

मुझे लगता है कि इसका मतलब यह होगा कि मैं एक नकली दाओ के साथ सेवा का परीक्षण कर सकता हूं, सेवा विधियों को अंतिम रख सकता हूं और लेनदेन प्रबंधन के लिए इंटरफेस में डिफ़ॉल्ट तरीकों पर भरोसा नहीं कर सकता, और सेवा वर्ग तत्काल के अतिरिक्त ओवरहेड का महत्वपूर्ण प्रभाव नहीं होना चाहिए।

आपकी पिछली टिप्पणी में कोड उदाहरण का एक त्वरित उत्तर: आप try ब्लॉक को छोड़ सकते हैं और सीधे jdbi.useTransaction() पर कॉल कर सकते हैं। यह विधि एक अस्थायी हैंडल आवंटित करती है जो आपके कॉलबैक के वापस आने पर स्वचालित रूप से बंद हो जाती है।

हाय सब लोग, एक पीआर # 1579 है - जेडीबीआई 3.10.0 के रूप में, CreateSqlObject और ऑन डिमांड (आखिरकार) अच्छी तरह से एक साथ खेलना चाहिए।