हाइबरनेट - ट्यूटोरियल किस बारे में चुप हैं

एक समस्या मॉडल को एक संबंध में मैप करने में समस्याएं

समस्या 1. वंशानुक्रम और बहुरूपी प्रश्न।

1. सभी वारिस एक ही तालिका में हैं:
   @ वंशानुक्रम (रणनीति = InheritanceType.SINGLE_TABLE)
   
   
   
   इस मामले में, सामान्य क्षेत्र और वारिस के क्षेत्र एक तालिका में स्थित हैं। इस रणनीति का उपयोग करते हुए, हम संस्थाओं का चयन करते समय जुड़ने से बचते हैं। Minuses में से, यह ध्यान देने योग्य है कि, सबसे पहले, हम रिलेशनल मॉडल में "बल" कॉलम के लिए "NOT NULL" प्रतिबंध सेट नहीं कर सकते हैं, और दूसरी बात, हम तीसरा सामान्य रूप खो देते हैं। (गैर-प्रमुख विशेषताओं की एक सकरात्मक निर्भरता प्रकट होती है: बल और डिस्क)।
   
   वैसे, इस कारण सहित, एक शून्य क्षेत्र बाधा को निर्दिष्ट करने के 2 तरीके हैं - NotNull सत्यापन के लिए जिम्मेदार है; @ कॉलम (अशक्त = सत्य) - डेटाबेस में अशक्त बाधा के लिए जिम्मेदार।
   
   मेरी राय में, किसी ऑब्जेक्ट मॉडल को संबंधपरक मॉडल में मैप करने का यह सबसे अच्छा तरीका है।
   
2. इकाई-विशिष्ट फ़ील्ड एक अलग तालिका में हैं।
   
   @ वंशानुक्रम (कार्यनीति = InheritanceType.JOINED)
   
   
   
   इस मामले में, सामान्य फ़ील्ड को एक सामान्य तालिका में संग्रहीत किया जाता है, और बाल संस्थाओं के लिए विशिष्ट अलग-अलग लोगों में संग्रहीत किए जाते हैं। इस रणनीति का उपयोग करते हुए, हमें एक इकाई का चयन करते समय एक JOIN मिलता है, लेकिन अब हम तीसरे सामान्य रूप को सहेजते हैं, और हम डेटाबेस में एक NOT NULL बाधा भी निर्दिष्ट कर सकते हैं।
3. प्रत्येक इकाई की अपनी तालिका है।
   
   @ InheritanceType.TABLE_PER_CLASS
   
   
   
   इस मामले में, हमारे पास एक सामान्य तालिका नहीं है। इस रणनीति का उपयोग करते हुए, हम बहुरूपी प्रश्नों के लिए UNION का उपयोग करते हैं। हमें प्राथमिक कुंजी जनरेटर और अन्य अखंडता बाधाओं के साथ समस्या हो रही है। इस प्रकार की विरासत मानचित्रण दृढ़ता से हतोत्साहित किया जाता है।

समस्या 2. OOP में संरचना अनुपात

इकाई प्रबंधक

1. डेटाबेस कनेक्शन कैप्चर करना
   
   यह सिर्फ एक दिलचस्प बिंदु है। हाइबरनेट ईएम प्राप्त करने के समय कनेक्शन पर कब्जा नहीं करता है, लेकिन डेटाबेस में पहली बार पहुंच जाता है या लेनदेन को खोलता है (हालांकि यह समस्या हल हो सकती है )। यह व्यस्त कनेक्शन के समय को कम करने के लिए किया जाता है। ईएम-ए की प्राप्ति के दौरान, जेटीए लेनदेन की उपस्थिति की जाँच की जाती है।
2. स्थायी संस्थाओं में हमेशा आईडी होती है
3. डेटाबेस में एक पंक्ति का वर्णन करने वाली इकाइयाँ संदर्भ के बराबर होती हैं
   जैसा कि ऊपर उल्लेख किया गया है, ईएम में पहले स्तर का कैश है, इसमें वस्तुओं की तुलना संदर्भ से की जाती है। तदनुसार, सवाल उठता है - बराबरी और हैशकोड को ओवरराइड करने के लिए किन क्षेत्रों का उपयोग किया जाना चाहिए? निम्नलिखित विकल्पों पर विचार करें:
   
   
   • सभी क्षेत्रों का उपयोग करें। बुरा विचार बराबरी LAZY क्षेत्रों को प्रभावित कर सकते हैं। वैसे, यह स्ट्रैसिंग विधि के लिए भी सही है।
   • आईडी का ही इस्तेमाल करें। एक सामान्य विचार है, लेकिन बारीकियां भी हैं। चूंकि नई संस्थाओं के लिए अक्सर आईडी एक जनरेटर को जारी रखता है। निम्नलिखित स्थिति संभव है:
     
     

     Entity foo = new Entity(); //   (id = null) set.put(foo); //   hashset em.persist(foo); // persist  (id = some value) set.contains(foo) == false // .. hashCode    

     
     
   • एक व्यावसायिक कुंजी (मोटे तौर पर बोलने वाले क्षेत्र, जो अद्वितीय हैं और पूर्ण नहीं हैं) का उपयोग करें। लेकिन यह विकल्प हमेशा सुविधाजनक नहीं होता है।
     
     वैसे, चूंकि हम NULL और UNIQUE की बात नहीं कर रहे हैं, इसलिए कभी-कभी NOT NULL तर्कों के साथ सार्वजनिक निर्माण करने के लिए सुविधाजनक होता है, और बिना तर्क के निर्माणकर्ता सुरक्षित रहता है।
   • बराबरी और हैशकोड को ओवरराइड न करें।
4. फ्लश कैसे काम करता है
   फ्लश - डेटाबेस में संचित इन्स-एस, अपडेट-एस और डिलीट-एस को निष्पादित करता है। डिफ़ॉल्ट रूप से, फ्लश मामलों में निष्पादित होता है:
   
   
   • क्वेरी निष्पादित करने से पहले (em.get के अपवाद के साथ), यह ACID सिद्धांत का अनुपालन करना आवश्यक है। उदाहरण के लिए: हमने हमले के विमान के जन्म की तारीख बदल दी, और फिर हम वयस्क हमले के विमान की संख्या प्राप्त करना चाहते थे।
     
     अगर हम CriteriaQuery या JPQL के बारे में बात कर रहे हैं, तो फ्लश को निष्पादित किया जाएगा यदि क्वेरी एक तालिका को प्रभावित करती है जिसकी इकाइयां पहले स्तर के कैश में हैं।
   • लेनदेन करते समय;
   • कभी-कभी एक नई इकाई को जारी रखते हुए - मामले में जब हम केवल डालने के माध्यम से अपनी आईडी प्राप्त कर सकते हैं।
   
   और अब थोड़ा परीक्षण। इस मामले में कितने UPDATE ऑपरेशन किए जाएंगे?
   
   

    val spaceCraft = em.find(SpaceCraft.class, 1L); spaceCraft.setCoords(...); spaceCraft.setCompanion( findNearestSpaceCraft(spacecraft) ); 

   
   एक दिलचस्प हाइबरनेट सुविधा फ्लश ऑपरेशन के तहत छिपी हुई है - यह डेटाबेस में पंक्तियों को लॉक करने में लगने वाले समय को कम करने की कोशिश कर रही है।
   
   यह भी ध्यान दें कि फ्लश ऑपरेशन के लिए अलग-अलग रणनीतियाँ हैं। उदाहरण के लिए, आप डेटाबेस में "विलय" परिवर्तन को रोक सकते हैं - इसे MANUAL कहा जाता है (यह गंदे जाँच तंत्र को भी निष्क्रिय कर देता है)।
   
5. गंदी जाँच
   
   डर्टी चेकिंग फ्लश ऑपरेशन के दौरान निष्पादित एक तंत्र है। इसका उद्देश्य उन संस्थाओं को खोजना है जो बदल गए हैं और उन्हें अपडेट करते हैं। इस तरह के एक तंत्र को लागू करने के लिए, हाइबरनेट को ऑब्जेक्ट की मूल प्रतिलिपि (वास्तविक वस्तु की तुलना किसके साथ की जाएगी) को स्टोर करना होगा। अधिक सटीक होने के लिए, हाइबरनेट वस्तु के क्षेत्रों की एक प्रति संग्रहीत करता है, न कि वस्तु को।
   
   यह ध्यान देने योग्य है कि यदि संस्थाओं का ग्राफ बड़ा है, तो गंदे चेकिंग का संचालन महंगा हो सकता है। यह मत भूलो कि हाइबरनेट संस्थाओं की 2 प्रतियां संग्रहीत करता है (मोटे तौर पर बोल रहा है)।
   इस प्रक्रिया की "लागत कम करने" के लिए, निम्नलिखित सुविधाओं का उपयोग करें:
   
   
   • em.detach / em.clear - EntityManager से निकाले गए निकाय
   • फ्लशमॉड = MANUAL- रीड ऑपरेशन्स में उपयोगी
   • अपरिवर्तनीय - गंदे जाँच कार्यों से भी बचता है
   
   
6. लेन-देन
   
   जैसा कि आप जानते हैं, हाइबरनेट आपको केवल एक लेनदेन के भीतर संस्थाओं को अपडेट करने की अनुमति देता है। पढ़ें ऑपरेशन अधिक स्वतंत्रता प्रदान करते हैं - हम स्पष्ट रूप से लेनदेन को खोलने के बिना उन्हें निष्पादित कर सकते हैं। लेकिन यह ठीक सवाल है: क्या रीड ऑपरेशन के लिए स्पष्ट रूप से लेन-देन खोलना इसके लायक है?
   
   मैं कुछ तथ्यों का हवाला दूंगा:
   
   
   • लेनदेन के अंदर डेटाबेस में किसी भी स्टेटमेंट को निष्पादित किया जाता है। भले ही हम स्पष्ट रूप से इसे नहीं खोलते। (ऑटो-कमिट मोड)।
   • एक नियम के रूप में, हम डेटाबेस के लिए एक प्रश्न तक सीमित नहीं हैं। उदाहरण के लिए: पहले 10 रिकॉर्ड प्राप्त करने के लिए, आप शायद रिकॉर्ड की कुल संख्या वापस करना चाहते हैं। और यह लगभग हमेशा 2 अनुरोध है।
   • यदि हम स्प्रिंग डेटा के बारे में बात कर रहे हैं, तो रिपॉजिटरी तरीके डिफ़ॉल्ट रूप से ट्रांजेक्शनल हैं, जबकि रीड मेथड्स केवल-पढ़ने के लिए हैं।
   • @Transactional स्प्रिंग एनोटेशन (रीडऑनली = सच) भी फ्लशमोड को प्रभावित करता है, अधिक सटीक रूप से, स्प्रिंग इसे MANUAL स्थिति में रखता है, इस प्रकार हाइबरनेट गंदी-जाँच नहीं करेगा।
   • एक या दो डेटाबेस प्रश्नों के साथ सिंथेटिक परीक्षण दिखाएगा कि ऑटो-कमिट तेज है। लेकिन मुकाबला मोड में, ऐसा नहीं हो सकता है। ( इस विषय पर उत्कृष्ट लेख , टिप्पणियाँ देखें)
   
   संक्षेप में: किसी लेनदेन में डेटाबेस के साथ किसी भी संचार को पूरा करने के लिए यह अच्छा अभ्यास है।
   

जनरेटर

• GenerationType.AUTO - जनरेटर चयन बोली पर आधारित है। सबसे अच्छा विकल्प नहीं है, क्योंकि "स्पष्ट निहितार्थ से बेहतर है" नियम यहां लागू होता है।
• GenerationType.IDENTITY जनरेटर को कॉन्फ़िगर करने का सबसे आसान तरीका है। यह तालिका में ऑटो-इंक्रीमेंट कॉलम पर निर्भर करता है। इसलिए, जारी रखने के लिए आईडी के साथ हमें सम्मिलित करने की आवश्यकता है। यही कारण है कि यह स्थगित की संभावना को समाप्त करता है और इसलिए बैचिंग करता है।
• GenerationType.SEQUENCE सबसे सुविधाजनक मामला है जब हम अनुक्रम से आईडी प्राप्त करते हैं।
• GenerationType.TABLE - इस मामले में हाइबरनेट एक अतिरिक्त तालिका के माध्यम से एक अनुक्रम का अनुकरण करता है। सबसे अच्छा विकल्प नहीं, क्योंकि इस तरह के एक समाधान में, हाइबरनेट को एक अलग लेनदेन और लॉक प्रति लाइन का उपयोग करना पड़ता है।

• कोई नहीं - कोई अनुकूलन नहीं। प्रत्येक आईडी के लिए हम अनुक्रम को खींचते हैं।
• पूल किए गए और पूल किए गए लो - इस मामले में, हमारे अनुक्रम को डेटाबेस में एक निश्चित अंतराल - एन से बढ़ना चाहिए (SequenceGenerator.allocationSize)। और आवेदन में, हमारे पास एक निश्चित पूल है, जिसमें से हम डेटाबेस तक पहुंच के बिना नई संस्थाओं को असाइन कर सकते हैं ..
• hilo - एक आईडी उत्पन्न करने के लिए, hilo एल्गोरिदम 2 नंबर का उपयोग करता है: hi (डेटाबेस में संग्रहीत - अनुक्रम कॉल से प्राप्त मूल्य) और lo (केवल एप्लिकेशन में संग्रहीत - SequenceGenerator.allocationSize)। इन नंबरों के आधार पर, आईडी बनाने के अंतराल की गणना इस प्रकार की जाती है: [(hi - 1) * lo + 1, hi * lo + 1]। स्पष्ट कारणों के लिए, इस एल्गोरिथ्म को पुराना माना जाता है और इसका उपयोग करने की अनुशंसा नहीं की जाती है।

• SequenceHiLoGenerator एक पुराना जनरेटर है जो hilo अनुकूलक का उपयोग करता है। डिफ़ॉल्ट रूप से चयनित होने पर हमारे पास hibernate.id.new_generator_mappings == झूठी संपत्ति है।
• SequenceStyleGenerator - डिफ़ॉल्ट रूप से उपयोग किया जाता है (यदि hibernate.id.new_generator_mappings == सत्य गुण)। यह जनरेटर कई ऑप्टिमाइज़र का समर्थन करता है, लेकिन डिफ़ॉल्ट को पूल किया गया है।

गतिरोध

 Thread #1: update entity(id = 3) update entity(id = 2) update entity(id = 1) Thread #2: update entity(id = 1) update entity(id = 2) update entity(id = 3) 

सेट, बैग, सूची

• सेट - दोहराव के बिना संस्थाओं का एक अनियंत्रित सेट;
• बैग - संस्थाओं का एक अनियंत्रित सेट;
• सूची संस्थाओं का एक निर्धारित समूह है।

• यदि आपके हाइबरनेट का संस्करण 5.0.8 से कम है, तो एक गंभीर बग है - HHH-5855 - जब एक बाल इकाई सम्मिलित करते हैं, तो इसका दोहराव संभव है (कैस्केडाइप के मामले में = MERGE और PERSIST);
• यदि आप ManyToMany संबंध के लिए बैग का उपयोग करते हैं, तो हाइबरनेट संग्रह से किसी इकाई को हटाते समय बेहद अनुचित प्रश्न उत्पन्न करता है - यह पहले सम्मिलित तालिका से सभी पंक्तियों को हटा देता है, और फिर सम्मिलित करता है;
• हाइबरनेट एक ही समय में एक ही इकाई के लिए कई बैग नहीं ला सकता है।

 //  bag spaceCraft.getCrew().add( luke ); //       //  set spaceCraft.getCrew().put( luke ); //      //        .     ManyToOne   : luke.setCurrentSpaceCraft( spaceCraft ); 

शक्ति संदर्भ

 //  bag spaceCraft.getCrew().add( em.getReference( User.class, 1L ) ); //      ,      

तारीख और समय

 setTimestamp(int i, Timestamp t, java.util.Calendar cal) 

• वांछित समयक्षेत्र JVM निर्धारित करें
• हाइबरनेट पैरामीटर का उपयोग करें - hibernate.jdbc.time_zone (5.2 में जोड़ा गया) - केवल ZonedDateTime और OffsetDateTime को ठीक करेगा
• TIMEZONE के साथ TIMESTAMP टाइप करें

 // LocalDateTime LocalDateTime.ofInstant( ts.toInstant(), ZoneId.systemDefault() ); // Instant ts.toInstant(); 

बैचिंग

• बैचिंग सक्षम करें और अधिकतम स्टेटमेंट सेट करें:
  hibernate.jdbc.batch_size (5 से 30 अनुशंसित)
• इन्सर्ट और अपडेट को सॉर्ट करने में सक्षम करें:
  hibernate.order_inserts
  hibernate.order_updates
  
• यदि हम वर्जनिंग का उपयोग करते हैं, तो हमें सक्षम करने की भी आवश्यकता है
  hibernate.jdbc.batch_versioned_data - यहां सावधान रहें, आपको अपडेट के दौरान प्रभावित लाइनों की संख्या देने में सक्षम होने के लिए jdbc ड्राइवर की आवश्यकता है।

एन + 1 समस्या

• पृष्ठांकन। OneToMany रिश्तों के मामले में, हाइबरनेट ऑफसेट और सीमा को निर्दिष्ट करने में सक्षम नहीं होगा। इसलिए, इन-मेमोरी में पेजिनेशन होगा।
• कार्टेशियन उत्पाद की समस्या एक ऐसी स्थिति है जब एक डेटाबेस एन * एम * के पंक्तियों को एम अध्याय और के लेखकों के साथ एन किताबें चुनने के लिए देता है।

• FetchMode - आपको बाल संस्थाओं के लोडिंग एल्गोरिथ्म को बदलने की अनुमति देता है। हमारे मामले में, हम निम्नलिखित में रुचि रखते हैं:
  • FetchType.SUBSELECT - एक अलग अनुरोध में बालक रिकॉर्ड्स। नकारात्मक पक्ष यह है कि मुख्य अनुरोध की सभी जटिलता को subselect में दोहराया जाता है।
  • BATCH (FetchType.SELECT + BatchSize annotation) - एक अलग अनुरोध के रूप में रिकॉर्ड भी लोड करता है, लेकिन साथ में सबक्विरी के साथ यह पैरेंट_ड इन (?;?;, ..., ..., N) जैसी स्थिति बनाता है।
  यह ध्यान देने योग्य है कि जब क्राइटेरिया एपीआई में भ्रूण का उपयोग किया जाता है, तो FetType को नजरअंदाज कर दिया जाता है - JOIN हमेशा उपयोग किया जाता है
• JPA EntityGraph और हाइबरनेट FetchProfile - आपको इकाई लोडिंग नियमों को एक अलग अमूर्त में बनाने की अनुमति देते हैं - मेरी राय में दोनों कार्यान्वयन असुविधाजनक हैं।

परीक्षण

• लॉगिंग
  • org.hibernate.SQL: डीबग
  • org.hibernate.type.descriptor.sql: ट्रेस
• आंकड़े
  • hibernate.generate_statistics

• DBUnit - आपको XML प्रारूप में डेटाबेस की स्थिति का वर्णन करने की अनुमति देता है। कभी-कभी यह सुविधाजनक है। लेकिन बेहतर फिर से सोचें कि क्या आपको इसकी आवश्यकता है।
• डेटा स्रोत-प्रॉक्सी
  • p6spy सबसे पुराने समाधानों में से एक है। उन्नत क्वेरी लॉगिंग, रनटाइम आदि प्रदान करता है।
  • com.vladmihalcea: db-use: 0.0.1 एन + 1 समस्याओं को खोजने के लिए एक उपयोगी उपयोगिता है। यह आपको क्वेरी लॉग करने की अनुमति भी देता है। रचना में एक दिलचस्प रीट्री एनोटेशन शामिल है, जो कि एक OptimisticLockException के मामले में लेन-देन को पुन: प्रयास करता है।
  • सूँघना - आप एनोटेशन के माध्यम से अनुरोधों की संख्या पर एक जोर बनाने के लिए अनुमति देता है। कुछ मायनों में, व्लादिमीर से निर्णय से अधिक सुरुचिपूर्ण।

साहित्य

• निकोलाई अलिमेनकोव की रिपोर्ट - चलो हाइबरनेट को फिर से तेज करें - यह वह रिपोर्ट थी जिसने मुझे हाइबरनेशन का अधिक गहराई से अध्ययन करने के लिए प्रेरित किया। नीचे वे संसाधन हैं जिनका मैंने उपयोग किया था।
• पुस्तक "जावा दृढ़ता एपीआई और हाइबरनेट"
• आधिकारिक दस्तावेज
• व्लाद एम। ब्लॉग
• जावा कमजोर डाइजेस्ट - दैनिक डाइजेस्ट (अप्रत्यक्ष रूप से विषय से संबंधित)