CODEWITHSUNDEEP
mongodbmeteorcollectionssubscription
user3236895
user3236895

Reputation: 1485

how meteor match subscription with client collection?

on meteor server side, this looks fine, which maps server side collection to publication

if (Meteor.isServer) { // This code only runs on the server 
Meteor.publish('tasks', function tasksPublication() { return Tasks.find(); }); }

and the following on the client side is also understandable, which maps subscription to publication by name.

Meteor.subscribe('tasks');

But I couldn't find in any tutorial or docs explaining how subscription and client side collections are mapped to each other. There is no code mapping tasks (subscription) to Tasks (client side collection). Meteor might assume the client collection uses the same name as the server side by both including the same collection declaration (Tasks = new Mongo.collection('Tasks');). But what if I want to use a different collection name on the client side? or what if the info sent by the server is a mix of fields from multiple collections, how do clients know which collections to store this info when they get it from subscription?

Upvotes: 0

Views: 80

Answers (2)

Ankit
Ankit

Reputation: 1128

Lets breakdown the code:

Meteor.publish('tasks', function() { 
    return Tasks.find(); 
});

Here we have defined a publication name 'tasks' which supplied data it has received from the function return Tasks.find().

Similarly, when subscribing, we refer to that particular publication- tasks in this case and we get those data.

Now coming to the part of linking it to the collection. In Meteor, when you define a collection, it should be defined on both client and server. So when you define a collection like Tasks = new Mongo.collection('tasklists');, On server, the Tasks object refers to the collection tasklists that the server will use to communicate with the mongoDB server. On the client, an object with the name Tasks is created to interact with the database minimongo created in client for tasklists. The Minimongo is a client side API in JS for MongoDB. (You can consider it as a client side replica of the mongoDB database).

So, on client side, you can define Tasks as anything as long as it is an object for the mongoDB collection tasklists- e.g AnyName=new Mongo.collection('tasklists');

Regarding how publication and subscription will know, which collection are we talking about: Publications send across something known as cursor which is related to a particular document(s) and collection in 'mongoDB'. As long as you get the collection name( tasklists) correct, you can have different object names(Tasks) on client and server.

Upvotes: 0

Mikkel
Mikkel

Reputation: 7777

This is part of the way Meteor works. It automatically synchronises data in collections between client and server. You don't need to worry about it, and you can't change it.

Your helper methods can pull data from different server collections, and put the data in arrays - you can read from different collections to do this, and you can do it reactively, so when the source collection changes it will run your helper again.

You can also define client only collections, which don't get saved to the server.

So you can probably do what you want, and if you then want to save something from your smooshed data, you would probably write a piece of code to extract the data to be updated into an object, and then save that.

Upvotes: 0

Related Questions