Jdbi: डेवलपर गाइड: v2 से v3 माइग्रेशन

एक छोटी परियोजना को स्थानांतरित करने से नोट्स:

नामांकित वर्ग (इसलिए आयात को हटाने और आईडीई को इसे ठीक करने देने जितना आसान नहीं है):

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

Jdbi create() फ़ैक्टरी पद्धति से बदल दिया गया है।

ResultSetMapper को RowMapper $ से बदल दिया गया है और map विधि में अब पंक्ति अनुक्रमणिका नहीं है। Jdbi 3 में ResultSetMapper नाम का एक वर्ग मौजूद है, लेकिन यह एक अलग उद्देश्य को पूरा करता है। @Mapper को @UseRowMapper $ से बदल दिया गया है। registerMapper() पर Jdbi को registerRowMapper() $ से बदल दिया गया है।

@BindIn को @BindList #$ से बदल दिया गया है और अब StringTemplate की आवश्यकता नहीं है।

डिफ़ॉल्ट Jdbi टेम्प्लेटिंग के साथ, कोण कोष्ठक को उद्धृत नहीं किया जाता है, जिसका अर्थ है कि IntelliJ आपके द्वारा टूल -> डेटाबेस -> उपयोगकर्ता पैटर्न के तहत पैरामीटर पैटर्न को कॉन्फ़िगर करने के बाद सिंटैक्स को समझता है।

Query में अब Map का डिफ़ॉल्ट प्रकार नहीं है और इस प्रकार list() को सीधे उस पर नहीं बुलाया जा सकता है। $#$23 list() #$ पर कॉल करने से पहले mapToMap() पर कॉल करें।

TransactionStatus अब मौजूद नहीं है।

TransactionConsumer.useTransaction() अब केवल Handle लेता है, इसलिए TransactionStatus तर्क को Jdbi पर Jdbi useTransaction() विधियों के साथ इसका उपयोग करते समय हटाया जाना चाहिए या Handle ।

TransactionCallback.inTransaction() अब केवल Handle लेता है, इसलिए TransactionStatus तर्क को Jdbi पर Jdbi inTransaction() विधियों के साथ इसका उपयोग करते समय हटाया जाना चाहिए या Handle ।

CallbackFailedException अब मौजूद नहीं है। HandleConsumer , HandleCallback , TransactionalConsumer , और TransactionalCallback जैसे विभिन्न कार्यात्मक इंटरफेस अब किसी भी अपवाद प्रकार को फेंक सकते हैं (लेकिन अनावश्यक जांच से बचने के लिए जेनेरिक का उपयोग प्रतिबंधित है) एक्सेप्शन हेंडलिंग)।

SQL ऑब्जेक्ट समर्थन अब डिफ़ॉल्ट रूप से उपलब्ध नहीं है। इसे प्रत्येक निर्मित Jdbi उदाहरण के लिए पंजीकृत किया जाना चाहिए।

IntelliJ का माइग्रेट रिफैक्टर माइग्रेशन को किकस्टार्ट करने में मददगार था।

धन्यवाद @electrum इसे एक साथ रखने के लिए! यह एक बड़ी मदद होगी

मेरी प्रस्तुति की समीक्षा से कुछ अतिरिक्त नोट:

• कलाकृतियों का नाम बदलकर org.jdbi:jdbi -> org. jdbi:jdbi3 , :jdbi3-sqlobject, :jdbi3-guava, आदि
• कोर पैकेज बदला गया: org.skife.jdbi.v2 -> org.jdbi.v3। इसका मतलब है कि जब आप माइग्रेट करते हैं तो v2 और v3 किसी प्रोजेक्ट पर एक साथ रह सकते हैं
• नाम बदला गया: GetHandle -> SqlObject
• v3 तर्क और मैपर कारखाने java.lang.reflect.Type का उपयोग करते हैं, जबकि v2 java.lang.Class उपयोग करते हैं। इसका अर्थ है कि v3 जटिल सामान्य प्रकार के हस्ताक्षरों को संभालने में सक्षम है जो v2 नहीं कर सका।
• v3 तर्क और मैपर कारखाने और एकल-विधि कार्यात्मक इंटरफेस जो एक वैकल्पिक लौटाते हैं। v2 में अलग-अलग स्वीकार () और बिल्ड () तरीके थे।
• v3 में SQL ऑब्जेक्ट प्रकार केवल सार्वजनिक इंटरफेस होना चाहिए - कोई वर्ग नहीं। विधि वापसी प्रकार भी सार्वजनिक होना चाहिए। यह SQL ऑब्जेक्ट कार्यान्वयन को CGLIB से java.lang.reflect.Proxy पर स्विच करने के कारण है, जो केवल इंटरफेस का समर्थन करता है।
• SQL ऑब्जेक्ट विधि पैरामीटर पर @Bind एनोटेशन को आपके कोड को -parameters सक्षम ध्वज के साथ संकलित करके वैकल्पिक बनाया जा सकता है।
• ऑन-डिमांड SQL ऑब्जेक्ट उन विधियों के साथ अच्छा नहीं खेलते हैं जो Iterables लौटाते हैं। ऑन-डिमांड ऑब्जेक्ट प्रत्येक विधि कॉल के बाद हैंडल को सख्ती से बंद कर देते हैं, और अब आपके लिए "दरवाजा खुला न रखें" ताकि आप पुनरावर्तनीय का उपभोग समाप्त कर सकें जैसा कि उन्होंने v2 में किया था। यह कनेक्शन लीक के एक प्रमुख स्रोत को बंद कर देता है।
• 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 ट्यूटोरियल से लिया गया है, जो मुझे लगता है कि सराहनीय रूप से न्यूनतम है। और वास्तव में, ग्रोवी जैसी जेवीएम-होस्टेड भाषा के साथ, जिसमें जावास्क्रिप्ट जैसा नक्शा बनाया गया है, आप शायद एक गैर-टाइप किए गए परिणाम को अधिक बार देखेंगे।

@javajosh आप https://github.com/jdbi/jdbi/pull/925 के बारे में क्या सोचते हैं?

@stevenschlansker क्या आपका मतलब #928 था?

@stevenschlansker निश्चित रूप से एक सुधार! लेकिन यह अभी भी v2 से अधिक वर्बोज़ है। :) यह मावेन, आदि में अधिक वाचालता के अतिरिक्त है। मैं बस JDBI को JUnit के रास्ते पर नहीं देखना चाहता, जिसने लोगों को v4 अपनाने के लिए संघर्ष किया क्योंकि इसमें कुछ अच्छी विशेषताएं थीं, लेकिन इससे कहीं अधिक जटिल थी v3 और v3 "काफी अच्छा" था। मेरे पास "withHandle" सिंटैक्स के बारे में वही भावना है (हालांकि मैं सभी लटकने वाले हैंडल को खत्म करने के लिए आपकी वृत्ति को समझता हूं)।

@javajosh यदि आप अधिक नियंत्रण चाहते हैं तो आपके पास अभी भी Jdbi.open() है, हालांकि हम अनुशंसा करते हैं कि आप सुरक्षा के लिए संसाधनों के साथ प्रयास करें ब्लॉक के अंदर इसका उपयोग करें।

v2 से v3 माइग्रेशन डॉक्स पर काम शुरू कर रहा है।

@javajosh ResultBearing.list() विधि पर वापस आ रहा है जो List<Map<String,Object>> लौटाता है: मुझे यकीन नहीं है कि यह एक अच्छा विचार था, खासकर रिलीज चक्र में देर से।

मैं क्रियात्मकता के बारे में आपकी चिंताओं के प्रति सहानुभूति रखता हूं, लेकिन यह क्रियात्मकता डेवलपर के इरादे को स्पष्ट करने के उद्देश्य को पूरा करती है:

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

पाठक की तुलना में स्पष्ट है:

handle.createQuery(sql)
    .list()

यह एक नाजुक बात है, और मैं आपकी स्थिति को चुनने से ईर्ष्या नहीं करता। JDBI एक अच्छा पुस्तकालय है, और मुझे खुशी है कि मैंने शब्दशः के बारे में अपनी चिंताओं को दर्ज किया है; क्या इस विशिष्ट मामले में एक सुविधा विधि जोड़ने का कोई मतलब है, मुझे यकीन नहीं है और मैं अपने फैसले पर भरोसा करूंगा, क्योंकि मैं इस परियोजना में गंभीरता से शामिल नहीं हूं! सुनने के लिए धन्यवाद!

कृपया हमें बताएं कि क्या आप इस बात का ठोस उदाहरण देते हैं कि यह छोटे नाम के साथ कैसे बेहतर है, या हम इसे कैसे सुधार सकते हैं इसका एक प्रदर्शन