आपको लगता है कि एक उपयोगकर्ता मानों डेटाबेस में अद्वितीय होना चाहिए दर्ज कर सकते हैं इससे पहले कि आप परिवर्तनों को सहेजने आप इस इनपुट सत्यापित करना चाहिए अनुमति देते हैं:
if (context.Customers.Any(c => c.SomeUniqueProperty == userInput))
// return to user with a message to change the input value
else
context.SaveChanges();
यह न केवल अद्वितीय बाधाओं के साथ मूल्यों के लिए मामला है डेटाबेस में, लेकिन विदेशी कुंजी मानों को दर्ज करने के लिए जो मौजूदा लक्ष्य रिकॉर्ड या प्राथमिक कुंजी मानों को संदर्भित करना चाहिए यदि प्राथमिक कुंजी डेटाबेस में स्वत: उत्पन्न नहीं होती है। ईएफ बाद की स्थिति में आपकी मदद नहीं करता है क्योंकि एक संदर्भ पूरी डेटाबेस तालिका की सामग्री को नहीं जानता है, बल्कि केवल उन संस्थाओं के बारे में है जो संदर्भ में संलग्न हैं। यह सच है कि ईएफ एक ही प्राथमिक कुंजी के साथ दो वस्तुओं को संलग्न करने से मना कर देगा लेकिन दो वस्तुओं को एक ही अद्वितीय कुंजी बाधा के साथ अनुमति देता है। लेकिन जब आप डेटाबेस में परिवर्तन सहेजते हैं तो यह प्राथमिक कुंजी बाधा उल्लंघन के खिलाफ पूरी तरह से आपकी रक्षा नहीं करता है।
संभावना नहीं है कि मामले में Any
जांच और SaveChanges
के बीच किसी अन्य उपयोगकर्ता एक ही मूल्य के साथ एक रिकॉर्ड में प्रवेश किया है, मैं संभाल करने के लिए संभव नहीं के रूप में घटित अपवाद पर विचार करेंगे और सिर्फ उपयोगकर्ता "बता एक उम्मीद त्रुटि हुई है, प्रयास करें फिर..."। यदि उपयोगकर्ता फिर से प्रयास करता है Any
चेक फिर से होता है और उसे ऊपर दिए गए कोड से इनपुट मान बदलने के लिए और अधिक उपयोगी संदेश मिल जाएगा।
ऐसी अनूठी कुंजी बाधा या प्राथमिक कुंजी बाधा उल्लंघन के लिए लौटाया गया अपवाद सामान्य DbUpdateException
है और आंतरिक अपवादों में से एक SqlException
होगा जो इसकी गुणों में से एक SQL सर्वर त्रुटि कोड के रूप में होता है। कोई अन्य विवरण केवल अपवाद संदेश में पाया जा सकता है "अद्वितीय कुंजी बाधा IX_SomeUniqueProperty_Index का उल्लंघन ..." या इसी तरह के। यदि आप उम्मीद करते हैं कि उपयोगकर्ता इस जानकारी के अनुसार समझ और प्रतिक्रिया दे सकता है तो आप इसे प्रदर्शित कर सकते हैं। अन्यथा आप संभावित संदेश या अन्य समस्याओं की जांच के लिए व्यवस्थापक या डेवलपर के लिए यह संदेश लॉग कर सकते हैं।
इसलिए, चूंकि मैं बैच अपडेट कर रहा हूं, इसलिए ग्राहकों में अपडेट/जोड़े गए रिकॉर्ड, और प्रत्येक रिकॉर्ड के माध्यम से लूप को यह जांचने की आवश्यकता होगी कि एक ही मूल्य के साथ मौजूदा रिकॉर्ड है या नहीं। मुझे पूरा यकीन नहीं है कि प्रदर्शन पर असर कैसे होगा जब 10+ रिकॉर्ड बदल दिए गए थे। या इस मामले में सिर्फ अपवाद पकड़ना बेहतर है? संदेश को स्थानीयकृत किया जाना चाहिए, इसलिए ऐसा लगता है कि मुझे एक ऐसी प्रक्रिया बनाने की आवश्यकता है जो IX_SomeUniqueProperty के लिए एक संदेश खोज करेगी, क्योंकि संदेश फ्रेंच पर भी हो सकता है, यदि ओएस फ्रेंच है (यदि मुझे गलत नहीं है), और मैं निर्भर नहीं हो सकता "उल्लंघन का ...." – Goran
@ गोरान: मैं देखता हूं, लेकिन मैं अभी भी अस्तित्व की जांच करने के लिए एक प्रश्न पूछूंगा। यदि आपको * अपडेट * की आवश्यकता है, जैसा कि आप कहते हैं, न केवल डालें, क्या आपको डेटाबेस में इकाई के लिए क्वेरी करने की आवश्यकता नहीं है? आप यह जानने के बिना अद्यतन और डालने के बीच निर्णय नहीं ले सकते कि क्या इकाई पहले ही डीबी में है या नहीं। – Slauma
अद्यतन और डालने के बीच निर्णय ईएफ द्वारा ही किया जाता है।ग्राहक संग्रह में जो भी इकाई मैंने जोड़ दी है उसे नया रिकॉर्ड माना जाता है, पहले ही असाइन किए गए पीके के साथ रिकॉर्ड अपडेट किए जाएंगे। मुझे जो कवर करने की ज़रूरत है वह वह मामला है जहां नेटवर्क पर उपयोगकर्ता ने एक रिकॉर्ड जोड़ा (क्लाइंट का डेटा अधिकांश मामलों में डेटाबेस डेटा के साथ अद्यतित नहीं है, क्योंकि इसके लिए निरंतर पुनर्संरचनाकरण की आवश्यकता होगी), इसलिए अंतिम के बीच 15 मिनट बीत सकते हैं डेटा लोड, और परिवर्तन कॉल सहेजें। इस कारण से मैं न केवल उस डेटा पर निर्भर करता हूं जो क्लाइंट पर कैश किया गया है ताकि यह जांच सके कि अद्वितीय (या कोई अन्य) बाधाएं हैं या नहीं। – Goran