2012-12-19 42 views
12

क्या एनएचबर्ननेट के लिए dynamic-insert/dynamic-update का उपयोग करने का कोई कारण नहीं है? एकमात्र कारण मैं पूछता हूं कि ऐसा लगता है कि मैं डिफ़ॉल्ट के रूप में सक्षम होना चाहता हूं, ऐसा कुछ नहीं जिसे मुझे कॉन्फ़िगर करना होगा।NHibernate गतिशील-अद्यतन नुकसान?

क्या इन गतिशील गुणों का उपयोग करते समय जागरूक होने के लिए कोई गठिया है?

उत्तर

23

कुछ इकाइयों के लिए, आप डायनामिक अपडेट के बावजूद एक अमान्य स्थिति बना सकते हैं। मान लीजिए कि आपके पास ClassBoolean संपत्ति A और एक तर्कसंगत रूप से निर्भर Integer संपत्ति B है। अगर संपत्ति ATrue है, तो संपत्ति B केवल ऋणात्मक संख्या हो सकती है, जबकि यदि संपत्ति AFalse है, तो संपत्ति B केवल सकारात्मक संख्या हो सकती है।

मान लें कि दो उपयोगकर्ता दोनों इस अवधि के एक उदाहरण के साथ किसी दिए गए समय अवधि के साथ बातचीत करते हैं। शुरू करने के लिए, उन ऐलिस और बॉब दोनों डेटाबेस से इस वर्ग के अमल में लाना, A = सच और की प्रारंभिक मूल्यों के साथ B = -50

Database Alice  Bob 
A: True A: True  A: True 
B: -50  B: -50  B: -50 
VALID  VALID  VALID 

उपयोगकर्ता ऐलिस बदलता है AFalse करने और 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 को सक्षम करें। इसके परिणामस्वरूप कुछ अतिरिक्त डेटाबेस कॉल और थोड़ा धीमा प्रदर्शन हो सकता है। दूसरा एनएचबीर्नेट में वर्जनिंग का उपयोग करना है, जिसका अर्थ यह होगा कि जब बॉब अपने रिकॉर्ड को बचाने की कोशिश करता है, तो एनएचबेर्नेट की सम्मिलित क्वेरी किसी भी लिखने को ट्रिगर नहीं करती है और एक स्टेल डेटा अपवाद फेंक देती है (जिसे सुन्दर तरीके से संभाला जा सकता है)। आप डेटाबेस में अपनी कक्षा की तार्किक आवश्यकताओं को भी संहिताबद्ध कर सकते हैं, हालांकि आपको यह सुनिश्चित करने के लिए सावधान रहना होगा कि समय और समय पर डेटाबेस और प्रोग्राम दोनों में समान कोडित आवश्यकताएं होंगी, और आपके पास कई जगहें होंगी आवश्यकताएं बदलते समय परिवर्तन करें, जो हमेशा एक सार्थक ओवरहेड नहीं होता है।

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

+0

बहुत जानकारीपूर्ण। मुझे चयन-पहले-अपडेट के बारे में भी पता नहीं था। निश्चित रूप से इसे ध्यान में रखेगा। – Sam

+2

इस उदाहरण में एप्लिकेशन ने अमान्य स्थिति में होने पर उपयोगकर्ता को परिवर्तन करने की अनुमति दी। कक्षा को उन गुणों तक पहुंच को समाहित करना चाहिए ताकि व्यापार नियम लागू किया जा सके, और/या लेनदेन किए जाने से पहले इकाई को सत्यापित किया जाना चाहिए। मुझे नहीं लगता कि इसमें गतिशील अद्यतन के साथ कुछ भी करना है। –

+0

आप यहां सबक खो रहे हैं: बॉब की इकाई की प्रति अमान्य स्थिति में नहीं थी। इकाई केवल अमान्य हो गई जब गतिशील अद्यतन ने संपत्ति बी के मूल्य को बदल दिया, यह जानकारी के बिना कि संपत्ति ए के निरंतर मूल्य उस मान को अमान्य बना देंगे। –

5

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

आप श्रोताओं और इंटरसेप्टर के साथ मुद्दों में भाग ले सकते हैं, this question देखें।

मैंने इसे अपने एनएचबीरनेट अनुप्रयोगों में कोई समस्या नहीं है। मेरा जवाब नहीं है, इसका उपयोग करने के लिए कोई अच्छा कारण नहीं है।

+0

कैशिंग के बारे में आपकी टिप्पणियों पर उत्सुक। जब मैं log4net का उपयोग कर जेनरेट किए गए एसक्यूएल को देखता हूं, तो यह अभी भी पैरामीटरयुक्त प्रश्नों का उपयोग कर रहा है। क्या वे अभी भी रेखा के साथ कहीं भी कैश नहीं होंगे? साथ ही, गतिशील प्रश्नों को छोड़ने से भी उन फ़ील्ड को अपडेट करके प्रदर्शन प्रभावित नहीं हुआ है जो बदले नहीं गए हैं? या वह लागत नगण्य है? प्रतिक्रिया के लिए धन्यवाद। – Sam

+2

NHibernate एक स्थिर क्वेरी प्रारूप को कैश कर सकता है ताकि एक क्वेरी बनाना सिर्फ रिक्त स्थान भर रहा हो। गतिशील प्रश्नों के साथ, क्वेरी हर बार बनाई जानी चाहिए। सभी क्षेत्रों को अपडेट करने का प्रदर्शन हिट, यदि कोई है, डेटाबेस निर्भर है। कई कारक हैं लेकिन मेरी राय और अनुभव मुझे डायनामिक डालने और अपडेट का उपयोग करने की सलाह देता है। –