मैं यह कैसे निर्धारित करूं कि एक MongoDB दस्तावेज़ सत्यापन विफल क्यों हो रहा है?

14

मैं कैसे निर्धारित करूं कि क्यों एक MongoDB दस्तावेज़ सम्मिलित सत्यापन विफल हो रहा है? सभी मुझे वापस मिल गया है एक राइटर है जो कहता है "दस्तावेज़ विफल सत्यापन", जो बहुत उपयोगी नहीं है।

(यह अक्सर होता है, और मैं यह समझना चाहूंगा कि इन पर ठीक से डिबग कैसे किया जा सकता है, बजाय एक विशिष्ट उदाहरण के साथ मदद के लिए पूछना।)

mongodb debugging data-validation

— जोनाथन व्हीलर
स्रोत

11

MongoDB 3.2 के अनुसार, कारण दस्तावेज सत्यापन विफल होने पर कोई प्रतिक्रिया नहीं है: वर्तमान में समग्र सत्यापन अभिव्यक्ति वर्तमान में या तो सही ("ठीक है") या गलत ("दस्तावेज़ विफल सत्यापन") के रूप में मूल्यांकन करता है। सत्यापन व्यवहार को validationAction(त्रुटि / चेतावनी) और validationLevel(सख्त / मध्यम / बंद) कॉन्फ़िगरेशन विकल्पों के साथ समायोजित किया जा सकता है , लेकिन यह सत्यापन विफलताओं के लिए कोई और संदर्भ प्रदान नहीं करता है।

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

उदाहरण के लिए, वेब एप्लिकेशन के लिए उपयोगकर्ता इनपुट (आवश्यक फ़ील्ड, फ़ील्ड प्रारूप, ...) को आपके एप्लिकेशन में सबमिट करने या डेटाबेस में डालने / अपडेट करने का प्रयास करने से पहले ब्राउज़र में मान्य किया जाना चाहिए।

हालाँकि, डेटा की गुणवत्ता सुनिश्चित करने के लिए कई स्तरों पर मान्य करने का कोई मतलब नहीं है और सत्यापन विफलताओं के निदान के लिए कुछ संदर्भ बहुत उपयोगी होंगे। एक प्रासंगिक खुली सुविधा का अनुरोध है जिसे आप MongoDB अंक ट्रैकर में देख सकते हैं / अप-वोट कर सकते हैं: SERVER-20547: एक ऑपरेशन के दस्तावेज सत्यापन में विफल होने का कारण बताएं ।

अधिक जानकारी के लिए आपको दस्तावेज़ सत्यापन में भी रुचि हो सकती है - भाग 1: अपने दस्तावेज़ों पर नियंत्रण की उचित राशि जोड़ना । यह MongoDB 3.2 पर के रूप में सामान्य पेशेवरों और दस्तावेज़ सत्यापन के विपक्ष के कुछ पर प्रकाश डाला गया है, और के आधार पर परिणाम के लिए एक संदर्भ तालिका में शामिल हैं validationActionऔर validationLevelकॉन्फ़िगरेशन विकल्प।

— Stennie
स्रोत

2

धन्यवाद! लगता है कि मैं यहाँ कुछ भी याद नहीं था। हम वास्तव में अपने आवेदन में अपना अधिकांश सत्यापन करते हैं, लेकिन हम निम्न-स्तरीय जांच को MongoDB सत्यापनकर्ताओं के रूप में छोड़ देते हैं, ज्यादातर यह सुनिश्चित करने के लिए कि हमारे सॉफ़्टवेयर इंजीनियर (और खुद) उत्पादन के दौरान उपयोगकर्ता त्रुटियों को खोजने के बजाय, विकास के दौरान बग पैदा नहीं कर रहे हैं। मैंने JIRA को वोट दिया है। चीयर्स!

— जोनाथन व्हीलर

समस्या यह है कि स्कीमा प्रारूप "सेमी-स्टैंडर्ड" है यानी मोंगोडीबी एक्सटेंशन के साथ, इसलिए यह अभी भी पता लगाना मुश्किल है कि मानक JSON स्कीमा सत्यापनकर्ताओं का उपयोग करने का कारण क्या है।

— हेंडी इरावन

1

@HendyIrawan हाँ, MongoDB डेटा प्रकारों के लिए JSON स्कीमा के लिए कुछ एक्सटेंशन हैं, इसलिए सख्त सत्यापन के लिए अतिरिक्त ग्राहक सत्यापन या परिवर्तन की आवश्यकता होगी। मैंने mongo-schemerNode.js के लिए कुछ उदाहरणों को देखा है , जो AJV (एक और JSON स्कीमा सत्यापनकर्ता) पर बनाता है ।

— स्टेनी

1

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

यदि किसी फ़ील्ड की आवश्यकता थी, लेकिन यह गायब, खाली, या गलत तरीके से दिखाता है तो कम से कम यह आपकी खोज को बताता है। यदि डेटा सही दिखता है, तो स्कीमा में निर्दिष्ट मान्यताओं पर एक नज़र डालें।

— Serexx
स्रोत