उल्का को समझना प्रकाशित / सदस्यता लें

संग्रह, प्रकाशन और सदस्यता उल्का का एक मुश्किल क्षेत्र है, जिसके बारे में दस्तावेज़ीकरण अधिक विस्तार से चर्चा कर सकता है, ताकि बार-बार होने वाले भ्रम से बचा जा सके, जो कभी-कभी भ्रमित करने वाली शब्दावली से बढ़ जाता है।

यहाँ साचा ग्रीफ़ (डिस्कवरमेटर के सह-लेखक) एक स्लाइड में प्रकाशनों और सदस्यताओं के बारे में बता रहे हैं:

ठीक से समझने के लिए कि आपको find() call पर कॉल करने की आवश्यकता क्यों है? एक से अधिक बार, आपको यह समझने की आवश्यकता है कि उल्का में संग्रह, प्रकाशन और सदस्यताएँ कैसे काम करती हैं:

1. आप MongoDB में संग्रह को परिभाषित करते हैं। अभी तक कोई उल्का शामिल नहीं है। इन संग्रहों में डेटाबेस रिकॉर्ड . होते हैं (जिसे मोंगो और उल्का दोनों द्वारा "दस्तावेज़" भी कहा जाता है, लेकिन एक "दस्तावेज़" डेटाबेस रिकॉर्ड की तुलना में अधिक सामान्य है; उदाहरण के लिए, एक अद्यतन विनिर्देश या एक क्वेरी चयनकर्ता भी दस्तावेज़ हैं - जावास्क्रिप्ट ऑब्जेक्ट जिसमें field: value शामिल हैं। कोड> जोड़े)।

2. फिर आप संग्रह को उल्का सर्वर पर . परिभाषित करते हैं के साथ

   MyCollection = new Mongo.Collection('collection-name-in-mongo')
   

   इन संग्रहों में सभी . शामिल हैं MongoDB संग्रह से डेटा, और आप MyCollection.find({...}) चला सकते हैं उन पर, जो एक कर्सर . लौटाएगा (रिकॉर्ड का एक सेट, उनके माध्यम से पुनरावृति करने और उन्हें वापस करने के तरीकों के साथ)।

3. यह कर्सर (अधिकांश समय) प्रकाशित . के लिए उपयोग किया जाता है (भेजें) रिकॉर्ड का एक सेट (जिसे "रिकॉर्ड सेट" कहा जाता है ) आप वैकल्पिक रूप से केवल कुछ प्रकाशित कर सकते हैं उन अभिलेखों से फ़ील्ड। यह रिकॉर्ड सेट है (नहीं संग्रह) कि ग्राहक सदस्यता लें को। प्रकाशन एक प्रकाशन फ़ंक्शन द्वारा किया जाता है, जिसे हर बार एक नया ग्राहक सदस्यता लेने के लिए कहा जाता है, और जो यह प्रबंधित करने के लिए पैरामीटर ले सकता है कि कौन से रिकॉर्ड वापस करने हैं (उदाहरण के लिए एक उपयोगकर्ता आईडी, केवल उस उपयोगकर्ता के दस्तावेज़ों को वापस करने के लिए)।

4. ग्राहक पर , आपके पास Minimongo संग्रह हैं जो आंशिक रूप से . हैं मिरर कुछ सर्वर से रिकॉर्ड की। "आंशिक रूप से" क्योंकि उनमें केवल कुछ फ़ील्ड हो सकते हैं, और "कुछ रिकॉर्ड" हो सकते हैं क्योंकि आप आमतौर पर क्लाइंट को केवल वही रिकॉर्ड भेजना चाहते हैं, जो पेज लोड को तेज़ करने के लिए आवश्यक हैं, और केवल वे जिन्हें इसकी आवश्यकता है और एक्सेस करने की अनुमति है।

   <ब्लॉकक्वॉट>

   मिनिमोंगो अनिवार्य रूप से शुद्ध जावास्क्रिप्ट में मोंगो का एक इन-मेमोरी, गैर-निरंतर कार्यान्वयन है। यह एक स्थानीय कैश के रूप में कार्य करता है जो उस डेटाबेस के सबसेट को संग्रहीत करता है जिसके साथ यह क्लाइंट काम कर रहा है। सर्वर से बात किए बिना, क्लाइंट पर क्वेरी (ढूंढें) सीधे इस कैश से प्रस्तुत की जाती हैं।

   ये मिनिमोंगो संग्रह शुरू में खाली हैं। वे

   . से भरे हुए हैं

   Meteor.subscribe('record-set-name')
   

   कॉल। ध्यान दें कि सदस्यता लेने का पैरामीटर संग्रह नाम नहीं है; यह एक रिकॉर्ड सेट . का नाम है कि सर्वर publish . में उपयोग किया जाता है बुलाना। subscribe() कॉल क्लाइंट को रिकॉर्ड सेट में सब्सक्राइब करता है - सर्वर संग्रह से रिकॉर्ड का एक सबसेट (उदाहरण के लिए हाल ही में 100 ब्लॉग पोस्ट), प्रत्येक रिकॉर्ड में सभी या फ़ील्ड के सबसेट के साथ (उदाहरण के लिए केवल title और date ) मिनिमोंगो कैसे जानता है कि आने वाले रिकॉर्ड को किस संग्रह में रखा जाए? संग्रह का नाम होगा collection प्रकाशित हैंडलर के added . में प्रयुक्त तर्क , changed , और removed कॉलबैक, या यदि वे गायब हैं (जो कि ज्यादातर समय होता है), तो यह सर्वर पर MongoDB संग्रह का नाम होगा।

रिकॉर्ड संशोधित करना

यह वह जगह है जहां उल्का चीजों को बहुत सुविधाजनक बनाता है:जब आप क्लाइंट पर मिनिमोंगो संग्रह में एक रिकॉर्ड (दस्तावेज़) को संशोधित करते हैं, तो उल्का उस पर निर्भर सभी टेम्पलेट्स को तुरंत अपडेट कर देगा, और सर्वर पर परिवर्तन भी वापस भेज देगा, जो बदले में MongoDB में परिवर्तनों को संग्रहीत करेगा और उन्हें उन उपयुक्त ग्राहकों को भेजेगा जिन्होंने उस दस्तावेज़ सहित एक रिकॉर्ड सेट की सदस्यता ली है। इसे विलंबता क्षतिपूर्ति . कहा जाता है और उल्का के सात प्रमुख सिद्धांतों में से एक है।

एकाधिक सदस्यता

आपके पास सदस्यताओं का एक समूह हो सकता है जो अलग-अलग रिकॉर्ड में खींचता है, लेकिन वे सभी क्लाइंट पर एक ही संग्रह में समाप्त हो जाएंगे यदि सर्वर पर एक ही संग्रह से आए, उनके _id के आधार पर . यह स्पष्ट रूप से समझाया नहीं गया है, लेकिन उल्का डॉक्स द्वारा निहित है:

जब आप किसी रिकॉर्ड सेट की सदस्यता लेते हैं, तो यह सर्वर को क्लाइंट को रिकॉर्ड भेजने के लिए कहता है। क्लाइंट इन अभिलेखों को स्थानीय मिनिमोंगो संग्रह में संग्रहीत करता है, उसी नाम के साथ collection प्रकाशित हैंडलर के added . में प्रयुक्त तर्क , changed , और removed कॉलबैक। जब तक आप मिलान संग्रह नाम के साथ क्लाइंट पर Mongo.Collection घोषित नहीं करते तब तक उल्का आने वाली विशेषताओं को कतारबद्ध करेगा।

जो समझाया नहीं गया है वह यह है कि जब आप नहीं करते हैं तो क्या होता है स्पष्ट रूप से added का उपयोग करें , changed और removed , या हैंडलर को बिल्कुल भी प्रकाशित करें - जो कि ज्यादातर समय होता है। इस सबसे आम मामले में, संग्रह तर्क (आश्चर्यजनक रूप से) चरण 1 पर सर्वर पर घोषित मोंगोडीबी संग्रह के नाम से लिया गया है। लेकिन इसका मतलब यह है कि आपके पास अलग-अलग नामों के साथ अलग-अलग प्रकाशन और सदस्यता हो सकती है, और सभी रिकॉर्ड क्लाइंट पर उसी संग्रह में समाप्त हो जाएंगे। शीर्ष स्तरीय फ़ील्ड . के स्तर तक नीचे , उल्का दस्तावेजों के बीच एक सेट यूनियन का प्रदर्शन करने का ध्यान रखता है, जैसे कि सदस्यता ओवरलैप हो सकती है - ऐसे कार्यों को प्रकाशित करें जो क्लाइंट के साथ-साथ और क्लाइंट पर अलग-अलग शीर्ष स्तर के क्षेत्रों को शिप करते हैं, संग्रह में दस्तावेज़ दोनों का मिलन होगा फ़ील्ड के सेट.

उदाहरण:क्लाइंट पर एक ही संग्रह को भरने वाली एकाधिक सदस्यता

आपके पास एक BlogPosts संग्रह है, जिसे आप सर्वर और क्लाइंट दोनों पर समान रूप से घोषित करते हैं, भले ही यह अलग-अलग काम करता हो:

BlogPosts = new Mongo.Collection('posts');

क्लाइंट पर, BlogPosts से रिकॉर्ड प्राप्त कर सकते हैं:

1. सबसे हाल की 10 ब्लॉग पोस्टों की सदस्यता

   // server
   Meteor.publish('posts-recent', function publishFunction() {
     return BlogPosts.find({}, {sort: {date: -1}, limit: 10});
   }
   // client
   Meteor.subscribe('posts-recent');
   

2. वर्तमान उपयोगकर्ता की पोस्ट की सदस्यता

   // server
   Meteor.publish('posts-current-user', function publishFunction() {
     return BlogPosts.find({author: this.userId}, {sort: {date: -1}, limit: 10});
     // this.userId is provided by Meteor - http://docs.meteor.com/#publish_userId
   }
   Meteor.publish('posts-by-user', function publishFunction(who) {
     return BlogPosts.find({authorId: who._id}, {sort: {date: -1}, limit: 10});
   }
   
   // client
   Meteor.subscribe('posts-current-user');
   Meteor.subscribe('posts-by-user', someUser);
   

3. सबसे लोकप्रिय पोस्ट की सदस्यता

4. आदि.

ये सभी दस्तावेज़ posts . से आते हैं MongoDB में संग्रह, BlogPosts . के माध्यम से सर्वर पर संग्रह, और अंत में BlogPosts ग्राहक पर संग्रह।

अब हम समझ सकते हैं कि आपको find() . पर कॉल करने की आवश्यकता क्यों है? एक से अधिक बार - क्लाइंट पर दूसरी बार होने पर, क्योंकि सभी सदस्यताओं के दस्तावेज़ एक ही संग्रह में समाप्त हो जाएंगे, और आपको केवल उन्हीं को लाने की आवश्यकता है जिनकी आप परवाह करते हैं। उदाहरण के लिए, क्लाइंट पर नवीनतम पोस्ट प्राप्त करने के लिए, आप बस सर्वर से क्वेरी को मिरर करें:

var recentPosts = BlogPosts.find({}, {sort: {date: -1}, limit: 10});

यह उन सभी दस्तावेज़ों/अभिलेखों पर एक कर्सर लौटाएगा जो क्लाइंट को अब तक प्राप्त हुए हैं, शीर्ष पोस्ट और उपयोगकर्ता की पोस्ट दोनों। (धन्यवाद जेफ्री)।