यह संभवतः उन लोगों के लिए एक पूर्ण स्पष्टीकरण के योग्य है जो इसे खोज सकते हैं, इसलिए इसे भावी पीढ़ी के लिए जोड़ सकते हैं।
विशेष रूप से जो लौटाया जाता है वह नोड.जेएस के लिए एक इवेंट स्ट्रीम है जो प्रभावी रूप से stream.Readable कुछ सुविधा विधियों के साथ इंटरफ़ेस। एक .count() वर्तमान में उनमें से एक नहीं है और वर्तमान उपयोग किए गए इंटरफ़ेस पर विचार करने का कोई मतलब नहीं होगा।
.stream()
कर्सर ऑब्जेक्ट्स के लिए उपलब्ध विधि, जब आप कार्यान्वयन पर विचार करते हैं तो "गिनती" का अधिक अर्थ नहीं होगा, क्योंकि इसका मतलब "स्ट्रीम" के रूप में संसाधित करना है जहां अंततः आप "अंत" तक पहुंचने जा रहे हैं लेकिन अन्यथा केवल प्रक्रिया करना चाहते हैं वहाँ पहुँचने तक।
यदि आप ड्राइवर से मानक "कर्सर" इंटरफ़ेस पर विचार करते हैं, तो कुछ ठोस कारण हैं कि एकत्रीकरण कर्सर समान क्यों नहीं है:
-
कर्सर निष्पादन से पहले "संशोधक" क्रियाओं को संसाधित करने की अनुमति देते हैं। ये
.sort(). की श्रेणियों में आते हैं ,.limit()और.skip(). इन सभी में वास्तव में पाइपलाइन में निर्दिष्ट एकत्रीकरण ढांचे में समकक्ष निर्देश हैं। पाइपलाइन चरणों के रूप में जो "कहीं भी" दिखाई दे सकते हैं और एक साधारण क्वेरी के लिए पोस्ट-प्रोसेसिंग विकल्प के रूप में नहीं, यह समान "कर्सर" प्रसंस्करण की पेशकश करने के लिए अधिक समझ में नहीं आता है। -
अन्य कर्सर संशोधक में
.hint(). जैसे विशेष शामिल हैं ,.min()और.max()जो "सूचकांक चयन" और प्रसंस्करण में परिवर्तन हैं। हालांकि ये एकत्रीकरण पाइपलाइन के लिए उपयोगी हो सकते हैं, वर्तमान में इन्हें क्वेरी चयन में शामिल करने का कोई आसान तरीका नहीं है। अधिकतर पिछले बिंदु से तर्क "कर्सर" के लिए एक ही प्रकार के इंटरफ़ेस का उपयोग करने के किसी भी बिंदु को ओवरराइड करता है।
अन्य विचार वे हैं जो आप वास्तव में एक कर्सर के साथ करना चाहते हैं और आप एक "वापस" क्यों चाहते हैं। चूंकि एक कर्सर आमतौर पर एक "एक तरफ यात्रा" होता है, इस अर्थ में कि वे आमतौर पर केवल एक अंत तक पहुंचने तक और प्रयोग करने योग्य "बैच" में संसाधित होते हैं, तो यह एक उचित निष्कर्ष निकालता है कि "गिनती" वास्तव में अंत में आती है, जब वास्तव में "कतार" समाप्त हो जाती है।
हालांकि यह सच है कि वास्तव में मानक "कर्सर" कार्यान्वयन में कुछ तरकीबें हैं, मुख्य कारण यह है कि यह सिर्फ एक "मेटा" डेटा अवधारणा का विस्तार करता है क्योंकि क्वेरी प्रोफाइलिंग इंजन को निर्धारित करने के लिए एक निश्चित संख्या में दस्तावेज़ को "स्कैन" करना होगा। परिणाम में लौटने के लिए आइटम।
हालांकि एकत्रीकरण ढांचा इस अवधारणा के साथ थोड़ा खेलता है। चूंकि न केवल वही परिणाम हैं जो मानक क्वेरी प्रोफाइलर के माध्यम से संसाधित किए जाएंगे, बल्कि अतिरिक्त चरण भी हैं। इनमें से किसी भी चरण में परिणामी "गणना" को "संशोधित" करने की क्षमता होती है जो वास्तव में संसाधित होने के लिए "स्ट्रीम" में वापस आ जाएगी।
दोबारा, यदि आप इसे अकादमिक दृष्टिकोण से देखना चाहते हैं और कहते हैं कि "ज़रूर, क्वेरी इंजन को गिनती के लिए 'मेटा डेटा' रखना चाहिए, लेकिन क्या हम ट्रैक नहीं कर सकते कि बाद में क्या संशोधित किया गया है?"। यह एक उचित तर्क होगा, और पाइपलाइन ऑपरेटर जैसे $match
और $group
या $unwind
और संभवत:$project सहित भी
और नया $redact
, सभी को प्रत्येक पाइपलाइन चरण में "संसाधित दस्तावेज़" का अपना ट्रैक रखने के लिए एक उचित मामला माना जा सकता है और "मेटा डेटा" में अपडेट किया जा सकता है जिसे संभवतः पूर्ण पाइपलाइन परिणाम गणना की व्याख्या करने के लिए वापस किया जा सकता है।
अंतिम तर्क उचित है, लेकिन यह भी विचार करें कि वर्तमान समय में एकत्रीकरण पाइपलाइन परिणामों के लिए "कर्सर" अवधारणा का कार्यान्वयन मोंगोडीबी के लिए एक नई अवधारणा है। यह उचित रूप से तर्क दिया जा सकता है कि पहले डिजाइन बिंदु पर सभी "उचित" अपेक्षाएं यह होंगी कि दस्तावेजों के संयोजन से "अधिकांश" परिणाम उस आकार के नहीं होंगे जो बीएसओएन सीमाओं के लिए प्रतिबंधित था। लेकिन जैसे-जैसे उपयोग का विस्तार होता है, धारणाएं बदल जाती हैं और चीजें अनुकूल होने के लिए बदल जाती हैं।
तो यह "संभवतः" बदला जा सकता है, लेकिन ऐसा नहीं है कि इसे "वर्तमान में" कैसे लागू किया जाता है। जबकि .count() एक मानक कर्सर कार्यान्वयन पर "मेटा डेटा" तक पहुंच होती है जहां स्कैन की गई संख्या दर्ज की जाती है, वर्तमान कार्यान्वयन पर किसी भी विधि के परिणामस्वरूप सभी कर्सर परिणाम प्राप्त होंगे, जैसे .itcount() खोल में करता है।
"डेटा" ईवेंट पर गिनती करके और अंत में "गिनती" के रूप में कुछ (संभवतः एक JSON स्ट्रीम जनरेटर) उत्सर्जित करके "कर्सर" आइटम को संसाधित करें। किसी भी उपयोग के मामले के लिए "अप-फ्रंट" गिनती की आवश्यकता होगी, यह वैसे भी कर्सर के लिए वैध उपयोग की तरह प्रतीत नहीं होगा, निश्चित रूप से आउटपुट उचित आकार का एक संपूर्ण दस्तावेज़ होगा।
