कुछ इकाइयों के लिए, आप डायनामिक अपडेट के बावजूद एक अमान्य स्थिति बना सकते हैं। मान लीजिए कि आपके पास Class
Boolean
संपत्ति A
और एक तर्कसंगत रूप से निर्भर Integer
संपत्ति B
है। अगर संपत्ति A
True
है, तो संपत्ति B
केवल ऋणात्मक संख्या हो सकती है, जबकि यदि संपत्ति A
False
है, तो संपत्ति B
केवल सकारात्मक संख्या हो सकती है।
मान लें कि दो उपयोगकर्ता दोनों इस अवधि के एक उदाहरण के साथ किसी दिए गए समय अवधि के साथ बातचीत करते हैं। शुरू करने के लिए, उन ऐलिस और बॉब दोनों डेटाबेस से इस वर्ग के अमल में लाना, A
= सच और की प्रारंभिक मूल्यों के साथ B
= -50
Database Alice Bob
A: True A: True A: True
B: -50 B: -50 B: -50
VALID VALID VALID
उपयोगकर्ता ऐलिस बदलता है A
False
करने और B
125, और यह करता है डेटाबेस में। अब हम इस स्थिति है:
Database Alice Bob
A: False A: False A: True
B: 125 B: 125 B: -50
VALID VALID VALID
उपयोगकर्ता बॉब A
परिवर्तन नहीं करता है, लेकिन -75 को B
बदलता है, तो डेटाबेस के लिए यह करता है। यदि डायनामिक अपडेट चालू हैं, तो NHibernate देखता है कि बॉब ने केवल B
से -75 बदल दिया है, और एक गतिशील अद्यतन जारी करता है जो केवल B
के मान को संपादित करता है। को A
सत्य होने तक नकारात्मक होने से सर्वर पर SQL सत्यापन था, तो आपको यहां एक SQL त्रुटि मिलेगी, लेकिन मान लीजिए कि आपने अपने SQL टेबल पर अपने सभी व्यावसायिक तर्क को पुन: उत्पन्न नहीं किया है। यहाँ परिणामी डेटा है:
Database Alice Bob
A: False A: False A: True
B: -75 B: 125 B: -75
INVALID VALID VALID
दोनों ऐलिस और बॉब वैध राज्यों है, लेकिन डाटाबेस एक अमान्य स्थिति में अब है! उपयोगकर्ता चार्ली साथ आता है और इस रिकॉर्ड को अमल करने की कोशिश करता:
Database Alice Bob Charlie
A: False A: False A: True A: False
B: -75 B: 125 B: -75 B: -75
INVALID VALID VALID INVALID
चार्ली संभावना आपके आवेदन से एक सत्यापन त्रुटि मिलती है जब NHibernate अपने वर्ग के नया उदाहरण के बी गुण सेट करने की कोशिश की।
तो, जब आपके पास तर्कसंगत रूप से निर्भर गुण हों, तो आपके पास इस स्थिति से बचने के लिए कुछ रणनीति होनी चाहिए। एक संभावना है कि इस इकाई के लिए select-before-update
को सक्षम करें। इसके परिणामस्वरूप कुछ अतिरिक्त डेटाबेस कॉल और थोड़ा धीमा प्रदर्शन हो सकता है। दूसरा एनएचबीर्नेट में वर्जनिंग का उपयोग करना है, जिसका अर्थ यह होगा कि जब बॉब अपने रिकॉर्ड को बचाने की कोशिश करता है, तो एनएचबेर्नेट की सम्मिलित क्वेरी किसी भी लिखने को ट्रिगर नहीं करती है और एक स्टेल डेटा अपवाद फेंक देती है (जिसे सुन्दर तरीके से संभाला जा सकता है)। आप डेटाबेस में अपनी कक्षा की तार्किक आवश्यकताओं को भी संहिताबद्ध कर सकते हैं, हालांकि आपको यह सुनिश्चित करने के लिए सावधान रहना होगा कि समय और समय पर डेटाबेस और प्रोग्राम दोनों में समान कोडित आवश्यकताएं होंगी, और आपके पास कई जगहें होंगी आवश्यकताएं बदलते समय परिवर्तन करें, जो हमेशा एक सार्थक ओवरहेड नहीं होता है।
तो संक्षेप में, कई परिस्थितियों में एक डेवलपर को गतिशील-अद्यतनों के सावधानी से विवरणों को संभालना होगा, यही कारण है कि यह डिफ़ॉल्ट रूप से चालू नहीं है।जब आप इसे चालू करते हैं, तो इस बात पर विचार करें कि क्या आपकी इकाई के आंशिक अपडेट समस्याएं पैदा कर सकते हैं, और यदि ऐसा है, तो उस समस्या के विरुद्ध सुरक्षा के लिए मैंने अनुशंसित रणनीतियों में से एक का उपयोग करें।
बहुत जानकारीपूर्ण। मुझे चयन-पहले-अपडेट के बारे में भी पता नहीं था। निश्चित रूप से इसे ध्यान में रखेगा। – Sam
इस उदाहरण में एप्लिकेशन ने अमान्य स्थिति में होने पर उपयोगकर्ता को परिवर्तन करने की अनुमति दी। कक्षा को उन गुणों तक पहुंच को समाहित करना चाहिए ताकि व्यापार नियम लागू किया जा सके, और/या लेनदेन किए जाने से पहले इकाई को सत्यापित किया जाना चाहिए। मुझे नहीं लगता कि इसमें गतिशील अद्यतन के साथ कुछ भी करना है। –
आप यहां सबक खो रहे हैं: बॉब की इकाई की प्रति अमान्य स्थिति में नहीं थी। इकाई केवल अमान्य हो गई जब गतिशील अद्यतन ने संपत्ति बी के मूल्य को बदल दिया, यह जानकारी के बिना कि संपत्ति ए के निरंतर मूल्य उस मान को अमान्य बना देंगे। –