प्रस्तुत तंत्र - विशेष क्यूबा मैजिक

दृश्य, या दृश्य, सीबीबीए मंच की अवधारणाओं में से एक है, जो वेब फ्रेमवर्क की दुनिया में सबसे आम नहीं है। यह समझने का मतलब है कि अपने आप को बेवकूफ गलतियों से बचाने के लिए, जब अपूर्ण डेटा लोडिंग के कारण, एप्लिकेशन अचानक काम करना बंद कर देता है। आइए देखें कि क्या अभ्यावेदन (वाक्य का उद्देश्य) है और यह वास्तव में सुविधाजनक क्यों है।

अनलोड डेटा की समस्या

आइए एक विषय क्षेत्र को सरल बनाएं और इसके उदाहरण का उपयोग करके समस्या पर विचार करें। मान लीजिए कि हमारे पास एक ग्राहक इकाई है जो एक ग्राहक- इकाई से कई-से-एक संबंध में संदर्भित करता है, दूसरे शब्दों में, खरीदार के पास एक निश्चित प्रकार का लिंक होता है जो इसका वर्णन करता है: उदाहरण के लिए, "कैश गाय", "स्नैपर", आदि। CustomerType इकाई में एक नाम विशेषता होती है जिसमें टाइप नाम संग्रहीत होता है।

और, शायद, सभी नए लोगों (या यहां तक ​​कि उन्नत उपयोगकर्ताओं) को CUBA में जल्दी या बाद में यह त्रुटि मिली:

IllegalStateException: Cannot get unfetched attribute [type] from detached object com.rtcab.cev.entity.Customer-e703700d-c977-bd8e-1a40-74afd88915af [detached].

मान लीजिए, आपने इसे अपनी आँखों से भी देखा? मैं - हाँ, सौ अलग-अलग स्थितियों में। इस लेख में, हम इस समस्या के कारण की जांच करेंगे कि यह क्यों मौजूद है, और इसे कैसे हल किया जाए।
शुरुआत के लिए, विचारों की अवधारणा का एक छोटा सा परिचय।

क्या नजरिया है?

CUBA में एक दृश्य अनिवार्य रूप से एक डेटाबेस में कॉलम का एक संग्रह है जिसे एक ही क्वेरी में एक साथ लोड किया जाना चाहिए।

मान लीजिए हम ग्राहक तालिका के साथ एक यूआई बनाना चाहते हैं, जहां पहला कॉलम ग्राहक का नाम है, और दूसरा ग्राहक टाइप विशेषता (जैसा कि ऊपर स्क्रीनशॉट में है) से टाइप नाम है। यह मान लेना तर्कसंगत है कि इस डेटा मॉडल में हमारे पास डेटाबेस में दो अलग-अलग टेबल होंगे, एक ग्राहक इकाई के लिए, दूसरा कस्टमटाइप के लिए। SELECT * from CEV_CUSTOMER हमें केवल एक टेबल (विशेषता name , आदि) से डेटा लौटाएगा। जाहिर है, अन्य तालिकाओं से भी डेटा प्राप्त करने के लिए, हम JOINs का उपयोग करेंगे।

JOIN का उपयोग करते हुए क्लासिक एसक्यूएल प्रश्नों का उपयोग करने के मामले में, संघों (संदर्भ विशेषताओं) का पदानुक्रम ग्राफ से एक फ्लैट सूची में फैलता है।
अनुवादक का नोट: दूसरे शब्दों में, तालिकाओं के बीच संबंध मिट जाते हैं, और परिणाम तालिका के संघ का प्रतिनिधित्व करने वाले एकल डेटा सरणी में प्रस्तुत किया जाता है।

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

फिर भी, डेटा को अभी भी डेटाबेस से किसी भी तरह उतारना और इकाई ग्राफ में बदलना होगा। इसके लिए, ऑब्जेक्ट-रिलेशनल मैपिंग मैकेनिज़्म (जो JPA है) में डेटाबेस के प्रश्नों के दो मुख्य दृष्टिकोण हैं।

आलसी लोडिंग बनाम। उत्सुक हो रहा है

डेटाबेस से डेटा प्राप्त करने के लिए आलसी लोडिंग और लालची लोडिंग दो संभावित रणनीतियाँ हैं। दोनों के बीच मूलभूत अंतर तब होता है जब लिंक्ड टेबल से डेटा लोड किया जाता है। एक बेहतर समझ के लिए एक छोटा सा उदाहरण:

पुस्तक "द हॉबिट या राउंड ट्रिप" के दृश्य को याद रखें, जहां गैंडलफ और बिल्बो की कंपनी के गनोम का एक समूह बीर्न के घर में रात भर रहने के लिए कहने की कोशिश कर रहा है? गैंडालफ ने बौनों को बदले में सख्ती से पेश आने का आदेश दिया और केवल तब जब वह ध्यान से बीरोन के साथ सहमत हुए और एक बार में उन्हें पेश करना शुरू कर दिया ताकि एक बार में 15 मेहमानों को समायोजित करने की आवश्यकता से मालिक को झटका न दें।

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

नैतिक यह है कि आलसी और लालची दोनों लोडिंग के अपने पक्ष और विपक्ष हैं। प्रत्येक विशिष्ट स्थिति में क्या लागू करना है, आप तय करते हैं।

अनुरोध समस्या N + 1

N + 1 क्वेरी समस्या अक्सर उत्पन्न होती है यदि आप जहाँ भी जाते हैं आलसी लोडिंग का उपयोग सोच-समझकर करते हैं। वर्णन करने के लिए, आइए ग्रेल्स कोड के एक टुकड़े को देखें। इसका मतलब यह नहीं है कि ग्रिल्स में सब कुछ आलसी लोड करता है (वास्तव में, आप खुद बूट विधि चुनते हैं)। ग्रिल्स में, डिफ़ॉल्ट रिटर्न एंटिटी द्वारा डेटाबेस के लिए एक क्वेरी इसकी तालिका से सभी विशेषताओं के साथ होती है। अनिवार्य रूप से, SELECT * FROM Pet से निष्पादित किया जाता है।

यदि आप संस्थाओं के बीच संबंधों में गहराई से जाना चाहते हैं, तो आपको इसे पोस्ट फैक्टम करना होगा। यहाँ एक उदाहरण है:

 function getPetOwnerNamesForPets(String nameOfPet) { def pets = Pet.findAll(sort:"name") { name == nameOfPet } def ownerNames = [] pets.each { ownerNames << it.owner.name } return ownerNames.join(", ") } 

ग्राफ यहां एक पंक्ति द्वारा it.owner.name किया गया है: it.owner.name । मालिक एक ऐसा रिश्ता है जिसे मूल अनुरोध ( Pet.findAll ) में लोड नहीं किया गया था। इस प्रकार, हर बार इस लाइन को कहा जाता है, GORM कुछ ऐसा करेगा जैसे SELECT * FROM Person WHERE id='…' । शुद्ध पानी आलसी लोड हो रहा है।

यदि आप SQL प्रश्नों की कुल संख्या की गणना करते हैं, तो आपको एन (प्रत्येक it.owner कॉल के लिए एक मालिक) + 1 (मूल Pet.findAll ) मिलता है। यदि आप संबंधित संस्थाओं के ग्राफ में गहराई से जाना चाहते हैं, तो संभावना है कि आपका डेटाबेस जल्दी से अपनी सीमाएं खोज लेगा।

एक डेवलपर के रूप में, आप इसे नोटिस करने की संभावना नहीं रखते हैं, क्योंकि आपके दृष्टिकोण से आप बस वस्तुओं के ग्राफ के आसपास जा रहे हैं। एक छोटी पंक्ति में यह छिपा हुआ घोंसला डेटाबेस वास्तविक दर्द का कारण बनता है और आलसी लोडिंग को कभी-कभी खतरनाक बना देता है।

एक हॉबी सादृश्य विकसित करने से, N + 1 की समस्या स्वयं इस प्रकार प्रकट हो सकती है: कल्पना करें कि गैंडालफ अपनी स्मृति में gnomes के नामों को संग्रहीत करने में सक्षम नहीं है। इसलिए, एक-एक करके बौनों का परिचय देते हुए, वह अपने समूह में वापस जाने के लिए मजबूर हो जाता है और अपने नाम के लिए बौना पूछता है। इस जानकारी के साथ, वह बीओर्न वापस जाता है और थोरिन का प्रतिनिधित्व करता है। फिर वह बिफूर, बोफूर, फिली, किली, डोरी, नोरी, ओरी, ओइन, ग्लिन, बालिन, डवलिन और बॉम्बूर के लिए इस युद्धाभ्यास को दोहराता है।

यह कल्पना करना आसान है कि इस तरह के परिदृश्य की संभावना नहीं होगी: क्या प्राप्तकर्ता इतने लंबे समय तक मांगी गई जानकारी का इंतजार करना चाहेगा? इसलिए, आपको इस दृष्टिकोण का बिना सोचे-समझे उपयोग नहीं करना चाहिए और अपने हठ मैपर की डिफ़ॉल्ट सेटिंग्स पर आँख बंद करके भरोसा करना चाहिए।

CUBA विचारों का उपयोग करके N + 1 प्रश्नों की समस्या का समाधान

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

 SELECT pet.name, person.name FROM Pet pet JOIN Person person ON pet.owner == person.id 

एक तरफ, दृश्य उन स्तंभों का वर्णन करता है जिन्हें मुख्य तालिका ( पेट ) (* के माध्यम से सभी विशेषताओं को लोड करने के बजाय) से लोड करने की आवश्यकता होती है, दूसरी ओर, यह उन स्तंभों का वर्णन करता है जिन्हें सी-जोइन तालिकाओं से लोड किया जाना चाहिए।

आप OR-Mapper के लिए SQL दृश्य के रूप में CUBA दृश्य की कल्पना कर सकते हैं: ऑपरेशन का सिद्धांत लगभग समान है।

CUBA प्लेटफ़ॉर्म में, आप बिना डेटा का उपयोग किए DataManager के माध्यम से एक क्वेरी आमंत्रित नहीं कर सकते। प्रलेखन एक उदाहरण प्रदान करता है:

 @Inject private DataManager dataManager; private Book loadBookById(UUID bookId) { LoadContext<Book> loadContext = LoadContext.create(Book.class) .setId(bookId).setView("book.edit"); return dataManager.load(loadContext); } 

यहां हम इसकी आईडी द्वारा पुस्तक डाउनलोड करना चाहते हैं। setView("book.edit") विधि, लोड संदर्भ बनाते समय, यह इंगित करती है कि किस डेटाबेस से पुस्तक को लोड किया जाना चाहिए। यदि आप किसी भी दृश्य को पास नहीं करते हैं, तो डेटा प्रबंधक तीन मानक विचारों में से एक का उपयोग करता है जो प्रत्येक इकाई में है: _local दृश्य । स्थानीय यहां उन विशेषताओं को संदर्भित करता है जो अन्य तालिकाओं का संदर्भ नहीं देते हैं, सब कुछ सरल है।

विचारों के माध्यम से IllegalStateException के साथ समस्या का समाधान

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

मैसेज IllegalStateException: डिटैच्ड ऑब्जेक्ट से अनफ़िल्टर्ड विशेषता [] प्राप्त नहीं कर सकता है इसका मतलब है कि आप कुछ विशेषता प्रदर्शित करने का प्रयास कर रहे हैं जो उस दृश्य में शामिल नहीं है जिसके साथ इकाई लोड की गई है।

जैसा कि आप देख सकते हैं, ब्राउज़ स्क्रीन डिस्क्रिप्टर में मैंने _local दृश्य का उपयोग किया है, और यह पूरी समस्या है:

 <dsContext> <groupDatasource id="customersDs" class="com.rtcab.cev.entity.Customer" view="_local"> <query> <![CDATA[select e from cev$Customer e]]> </query> </groupDatasource> </dsContext> 

त्रुटि से छुटकारा पाने के लिए, आपको पहले ग्राहक प्रकार को दृश्य में शामिल करना होगा। चूंकि हम _local के डिफ़ॉल्ट दृश्य को नहीं बदल सकते हैं, हम अपना स्वयं का बना सकते हैं। स्टूडियो में, यह किया जा सकता है, उदाहरण के लिए, निम्नानुसार (संस्थाओं पर राइट-क्लिक करें> दृश्य बनाएं):

या तो सीधे हमारे आवेदन के view.xml डिस्क्रिप्टर में:

 <view class="com.rtcab.cev.entity.Customer" extends="_local" name="customer-view"> <property name="type" view="_minimal"/> </view> 

उसके बाद, हम इस तरह से ब्राउज़ स्क्रीन में देखने के लिए लिंक को बदलते हैं:

 <groupDatasource id="customersDs" class="com.rtcab.cev.entity.Customer" view="customer-view"> <query> <![CDATA[select e from cev$Customer e]]> </query> </groupDatasource> 

यह पूरी तरह से समस्या को हल करता है, और अब ग्राहक डेटा स्क्रीन में लिंक डेटा प्रदर्शित होता है।

_मनिमल दृश्य और उदाहरण का नाम

विचारों के संदर्भ में और क्या ध्यान देने योग्य है _ न्यूनतम दृश्य। स्थानीय दृश्य की बहुत स्पष्ट परिभाषा है: इसमें इकाई के सभी गुण शामिल हैं, जो तालिका के प्रत्यक्ष गुण हैं (जो विदेशी कुंजी नहीं हैं)।

न्यूनतम प्रतिनिधित्व की परिभाषा इतनी स्पष्ट नहीं है, लेकिन काफी स्पष्ट भी है।

CUBA की एक इकाई उदाहरण नाम - उदाहरण नाम की अवधारणा है। उदाहरण का नाम अच्छे पुराने Java में toString() पद्धति के समतुल्य है। यह यूआई पर प्रदर्शन के लिए और लिंक में उपयोग के लिए एक इकाई का एक स्ट्रिंग प्रतिनिधित्व है। नाम का नाम NamePattern इकाई के एनोटेशन का उपयोग करके सेट किया गया है।

इसका उपयोग इस तरह किया जाता है: @NamePattern("%s (%s)|name,code") । हमारे पास दो परिणाम हैं:

उदाहरण का नाम यूआई को इकाई के मानचित्रण को परिभाषित करता है

सबसे पहले, उदाहरण का नाम यह निर्धारित करता है कि UI में क्या और किस क्रम में प्रदर्शित किया जाएगा यदि एक इकाई किसी अन्य इकाई को संदर्भित करता है (जैसा कि ग्राहक CustomerType को संदर्भित करता है)।

हमारे मामले में, ग्राहक प्रकार को कस्टम टाइप उदाहरण के नाम के रूप में प्रदर्शित किया जाएगा, जिसमें कोड कोष्ठक में जोड़ा गया है। यदि उदाहरण का नाम सेट नहीं है, तो इकाई वर्ग का नाम और विशिष्ट उदाहरण का आईडी प्रदर्शित किया जाएगा - सहमत हैं कि यह वह नहीं है जो उपयोगकर्ता देखना चाहते हैं। दोनों मामलों के उदाहरण के लिए नीचे स्क्रीनशॉट से पहले और बाद में देखें।

इंस्टेंस नाम न्यूनतम दृश्य विशेषताओं को परिभाषित करता है

NamePattern एनोटेशन को प्रभावित करने वाली दूसरी चीज है: ऊर्ध्वाधर बार के बाद निर्दिष्ट सभी विशेषताएँ स्वचालित रूप से एक _minimal दृश्य बनाती हैं। पहली नज़र में, यह स्पष्ट लगता है, क्योंकि किसी न किसी रूप में डेटा को UI में प्रदर्शित करने की आवश्यकता होती है, जिसका अर्थ है कि आपको पहले इसे डेटाबेस से डाउनलोड करना होगा। हालांकि, ईमानदार होने के लिए, मैं शायद ही कभी इस तथ्य के बारे में सोचता हूं।

यहां यह नोट करना महत्वपूर्ण है कि न्यूनतम प्रतिनिधित्व, यदि स्थानीय एक के साथ तुलना की जाए, तो अन्य संस्थाओं के संदर्भ हो सकते हैं। उदाहरण के लिए, ऊपर के उदाहरण से खरीदार के लिए, मैंने एक उदाहरण नाम सेट किया है, जिसमें ग्राहक इकाई का एक स्थानीय विशेषता ( name ) और एक संदर्भ विशेषता ( type ) शामिल है:

 @NamePattern("%s - %s|name,type") 

न्यूनतम प्रतिनिधित्व पुनरावर्ती रूप से उपयोग किया जा सकता है: (ग्राहक [उदाहरण नाम] -> ग्राहकप्रकार [उदाहरण नाम])

अनुवादक का नोट: लेख के प्रकाशन के बाद से, एक और सिस्टम व्यू दिखाई दिया है - _base व्यू, जिसमें @NamePattern एनोटेशन (यानी, वास्तव में _minimal + _local ) में निर्दिष्ट सभी स्थानीय गैर-सिस्टम विशेषताएँ और विशेषताएँ शामिल हैं।

निष्कर्ष

अंत में, हम सबसे महत्वपूर्ण विषय को संक्षेप में प्रस्तुत करते हैं। सीयूबीए में विचारों के लिए धन्यवाद, हम स्पष्ट रूप से इंगित कर सकते हैं कि डेटाबेस से क्या लोड होना चाहिए। दृश्य यह निर्धारित करते हैं कि लालची को क्या लोड किया जाएगा, जबकि अधिकांश अन्य रूपरेखा गुप्त रूप से आलसी लोडिंग करते हैं।

प्रतिनिधित्व एक बोझिल तंत्र की तरह लग सकता है, लेकिन लंबे समय में वे खुद को सही ठहराते हैं।

मुझे आशा है कि मैं एक सुलभ तरीके से समझाने में कामयाब रहा कि ये रहस्यमय दृश्य वास्तव में क्या हैं। बेशक, उनके उपयोग के लिए अधिक उन्नत परिदृश्य हैं, साथ ही सामान्य रूप से अभ्यावेदन और विशेष रूप से न्यूनतम अभ्यावेदन के साथ काम करने में कमियां हैं, लेकिन मैं इस बारे में किसी भी तरह एक अलग पोस्ट में लिखूंगा।