उल्का:संग्रह, चर, प्रकाशन और सदस्यता के नामों के बीच अंतर?

आइए उन अलग-अलग नामों के बीच अंतर करें जिनसे आपको उल्का प्रोग्रामिंग करते समय निपटना पड़ सकता है:

परिवर्तनीय नाम , जैसे Posts = new Meteor.Collection(...) . इनका उपयोग केवल इसलिए किया जाता है ताकि आपका कोड इस चर का उपयोग करना जानता हो। उल्का को पता नहीं है या परवाह नहीं है कि यह क्या है, हालांकि सम्मेलन पूंजीकरण करना है।
संग्रह के नाम , जैसे new Meteor.Collection("posts") . यह एक MongoDB संग्रह (सर्वर पर) या एक मिनीमोंगो संग्रह (क्लाइंट पर) के नाम पर मैप करता है।
प्रकाशन और सदस्यता के नाम , Meteor.publish("foo", ...) . में उपयोग किया जाता है या Meteor.subscribe("foo") . क्लाइंट को सर्वर पर कुछ डेटा की सदस्यता लेने के लिए इनका मिलान करना होगा।

उल्का डेटा मॉडल में आपको दो चीजों का मिलान करना होगा:

प्रकाशनों के नाम और उनकी संगत सदस्यताएं
(आमतौर पर) क्लाइंट और सर्वर पर संग्रह के नाम, यदि डिफ़ॉल्ट संग्रह मॉडल का उपयोग कर रहे हैं

सदस्यता का नाम हमेशा प्रकाशन के नाम से मेल खाना चाहिए। हालांकि, किसी दी गई सदस्यता के लिए भेजे गए संग्रह का सदस्यता नाम से कोई लेना-देना नहीं है। वास्तव में, कोई एक प्रकाशन में एक से अधिक कर्सर भेज सकता है या विभिन्न प्रकाशनों पर एक संग्रह या यहां तक कि प्रति प्रकाशन एक से अधिक सदस्यता , जो क्लाइंट में एक के रूप में विलय हुआ दिखाई देता है। आपके पास सर्वर और क्लाइंट में अलग-अलग संग्रह नाम भी हो सकते हैं; आगे पढ़ें...

आइए विभिन्न मामलों की समीक्षा करें:

साधारण सदस्यता मॉडल . यह वही है जो आप आमतौर पर सीधे उल्का डेमो में देखते हैं।

क्लाइंट और सर्वर पर,
```
Posts = new Meteor.Collection("posts");
```
केवल सर्वर पर:
```
Meteor.publish("postsPub", function() { 
    return Posts.find() 
});
```
केवल क्लाइंट पर:
```
Meteor.subscribe("postsPub")
```
यह Posts . को सिंक्रोनाइज़ करता है संग्रह (जिसे posts . नाम दिया गया है) डेटाबेस में) postsPub . नामक प्रकाशन का उपयोग करते हुए ।
एक प्रकाशन में अनेक संग्रह . आप एक सरणी का उपयोग करके एकल प्रकाशन के लिए एकाधिक कर्सर भेज सकते हैं।

क्लाइंट और सर्वर पर:
```
Posts = new Meteor.Collection("posts");
Comments = new Meteor.Collection("comments");
```
केवल सर्वर पर:
```
Meteor.publish("postsAndComments", function() { 
    return [ 
        Posts.find(), 
        Comments.find() 
    ]; 
});
```
केवल क्लाइंट पर:
```
Meteor.subscribe("postsAndComments");
```
यह Posts . को सिंक्रोनाइज़ करता है संग्रह के साथ-साथ Comments postsAndComments . नामक एकल प्रकाशन का उपयोग करके संग्रह . इस प्रकार का प्रकाशन संबंधपरक डेटा के लिए उपयुक्त है; उदाहरण के लिए, जहां आप केवल कुछ पोस्ट और केवल उन पोस्ट से जुड़ी टिप्पणियों को प्रकाशित करना चाहते हैं। देखें एक पैकेज जो इन कर्सर को स्वचालित रूप से बना सकता है ।
एक संग्रह के लिए अनेक प्रकाशन . आप एक संग्रह के लिए डेटा के अलग-अलग स्लाइस भेजने के लिए कई प्रकाशनों का उपयोग कर सकते हैं जो उल्का द्वारा स्वचालित रूप से विलय कर दिए जाते हैं।

सर्वर और क्लाइंट पर:
```
Posts = new Meteor.Collection("posts");
```
केवल सर्वर पर:
```
Meteor.publish("top10Posts", function() { 
    return Posts.find({}, {
        sort: {comments: -1}, 
        limit: 10
    });
});        
Meteor.publish("newest10Posts", function() { 
    return Posts.find({}, {
        sort: {timestamp: -1},
        limit: 10
    }); 
});
```
केवल क्लाइंट पर:
```
Meteor.subscribe("top10Posts");
Meteor.subscribe("newest10Posts");
```
यह दोनों 10 पोस्ट को सबसे अधिक टिप्पणियों के साथ-साथ साइट पर 10 नवीनतम पोस्ट उपयोगकर्ता के लिए धक्का देता है, जो डेटा के दोनों सेटों को एक Posts में विलय देखता है संग्रह। यदि नवीनतम पोस्टों में से एक भी सबसे अधिक टिप्पणियों वाली पोस्ट है या इसके विपरीत है, तो Posts संग्रह में 20 से कम आइटम होंगे। यह एक उदाहरण है कि कैसे उल्का में डेटा मॉडल आपको स्वयं विवरणों को लागू किए बिना शक्तिशाली डेटा विलय संचालन करने की अनुमति देता है।
प्रति प्रकाशन एक से अधिक सदस्यताएं। आप अलग-अलग तर्कों का उपयोग करके एक ही प्रकाशन से डेटा के कई सेट प्राप्त कर सकते हैं।

सर्वर और क्लाइंट पर:
```
Posts = new Meteor.Collection("posts");
```
केवल सर्वर पर:
```
Meteor.publish("postsByUser", function(user) { 
    return Posts.find({
        userId: user
    });
});        
```
केवल क्लाइंट पर:
```
Meteor.subscribe("postsByUser", "fooUser");
Meteor.subscribe("postsByUser", "barUser");
```
यह fooUser . द्वारा पोस्ट का कारण बनता है और barUser दोनों को Posts . में दिखाने के लिए संग्रह। यह मॉडल तब सुविधाजनक होता है जब आपके पास कई अलग-अलग संगणनाएँ होती हैं जो आपके डेटा के अलग-अलग स्लाइस को देख रही होती हैं और गतिशील रूप से अपडेट की जा सकती हैं। ध्यान दें कि जब आप किसी Deps.autorun(...) . के अंदर सदस्यता लेते हैं , उल्का कॉल stop() स्वचालित रूप से समान नाम वाले किसी भी पिछले सदस्यता हैंडल पर, लेकिन यदि आप इन सदस्यताओं का उपयोग autorun के बाहर कर रहे हैं आपको उन्हें स्वयं रोकना होगा। फ़िलहाल, आप autorun . के अंदर एक ही नाम से दो सब्सक्रिप्शन नहीं कर सकते हैं गणना, क्योंकि उल्का उन्हें अलग नहीं बता सकता।
मनमाने ढंग से डेटा को किसी प्रकाशन पर धकेलना. आप प्रकाशनों को पूरी तरह से अनुकूलित कर सकते हैं ताकि सर्वर और क्लाइंट पर समान संग्रह नामों की आवश्यकता न हो। वास्तव में, सर्वर उस डेटा को प्रकाशित कर सकता है जो किसी संग्रह द्वारा समर्थित नहीं है। ऐसा करने के लिए, आप प्रकाशित कार्यों के लिए API . का उपयोग कर सकते हैं ।

केवल सर्वर पर:
```
Posts = new Meteor.Collection("posts"); 

Meteor.publish("newPostsPub", function() {
    var sub = this;
    var subHandle = null;

    subHandle = Posts.find({}, {
        sort: {timestamp: -1},
        limit: 10
    })
    .observeChanges({
        added: function(id, fields) {
            sub.added("newposts", id, fields);            
        },
        changed: function(id, fields) {
            sub.changed("newposts", id, fields);            
        },
        removed: function(id) {
            sub.removed("newposts", id);
        }
    });

    sub.ready();

    sub.onStop(function() {
        subHandle.stop();
    })    
});
```
केवल क्लाइंट पर:
```
NewPosts = new Meteor.Collection("newposts");

Meteor.subscribe("newPostsPub");
```
यह Posts . से नवीनतम 10 पोस्ट को सिंक्रोनाइज़ करता है सर्वर पर संग्रह (Postscalled कहा जाता है) डेटाबेस में) NewPosts . पर क्लाइंट पर संग्रह (newposts . कहा जाता है) मिनिमोंगो में) newPostsPub . नामक प्रकाशन/सदस्यता का उपयोग करते हुए . ध्यान दें कि observeChanges observe . से भिन्न है , जो कई अन्य काम कर सकता है।

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

निबंध के लिए क्षमा करें :-) लेकिन बहुत से लोग इस बारे में भ्रमित हो जाते हैं और मैं हालांकि सभी मामलों का वर्णन करना उपयोगी होगा।