Reputation: 959
I am writing a web application that will dynamically inspect the collections (publications) of a DDP server. One of the issues that I'm running into is that once a Meteor collection is created it sticks around for the lifetime of the app:
foo = new Meteor.Collection("foo");
However, depending on what the user does with the application, I might no longer be interested in foo. It would be wasteful to have this collection linger around, as potentially I could end up with the entire database being stored on the client.
The issue is made worse by the fact that the client doesn't know which collections it is going to subscribe for. I think this causes issues with how template helpers are setup. All the examples I've seen so far show helpers returning just the results of a particular collection, like:
return foo.find();
I am still getting my head around how the reactive model works, but I'm guessing that if I would reassign foo:
foo = new Meteor.Collection("bar");
... the above helper code would not magically update to return the contents of 'bar'.
Update: Since suggestions revolve around using a combination of subscriptions and a single collection I'd thought I give some context as to why I am asking this question:
The application I'm developing is like PHP/Django admin, but for our own platform (cortex).
I could add functionality to the server that exposes the entire database through a single publication, and use subscription parameters to determine which collection(s) the publication should forward.
This becomes a bit of a nightmare though when changing the subscription. An unsubscribe doesn't clear the client minimongo collection, thus leaving residual data of the previous subscription. The client would become responsible for removing data in-between subscriptions:
foo_sub.stop();
foo.remove({});
bar_sub = remote.subscribe('bar'); // Assuming 'bar' publishes in 'foo'
Upvotes: 1
Views: 223
Reputation: 1367
I am sure you are struggling a bit with the terms.
As an example you can use this MeteorPad about FlowRouter and route based subscriptions.
http://meteorpad.com/pad/Ba5DTe94NjFi3ZTPA/Playground_Flow-Router_Chat
At least to answer your question quick:
1.) A Collection without a subscribe (you have to remove autopublish from your project) is empty on client
2.) A Collection defines just a document structure
3.) Depending on your projects you will use a number of collections, if you have different document models (like tables in sql)
4.) You should do template or route based subscriptions - best not application wide.
5.) You may subscribe with additional arguments to your publish method, so that only a few documents are requested and exchanged.
6.) You may use Col.find() on client, if for example your publish just send out the last 5 documents.
You should read about meteorhacks subs-manager package, this reduces the number of data / collection exchange and speeds up your app.
You find a good online article from sascha greif about publish subscribe for meteor.
I hope this ressource will guide you to the right decisions.
Have success Tom
UPDATE:
You may have a look to this MeteorPad to see the option to write you own publish method and push whatever you like content to client. This also may depend on an argument sended via submit.
http://meteorpad.com/pad/Zq4QdMW84rKGersFH/Sample_Publish_to_Local-Collection_Reactive_way
Imagine that you do not need to return Col.find()
you also can use Col.find()
on server and update with different documents.
Upvotes: 1