Tagging collection records per publication

[Dan Dascalescu]

The question is, how can the client tell which documents from a Meteor collection came from a particular subscription?

Use case: a Collection receives records from multiple subscriptions. Some of the subscriptions may have a particularly complex .find() selector on the server. whose calculation is costly (e.g. array of ids). Returning the equivalent cursor on the client requires running the same calculation for the server. This is a rather common code pattern:

1. if (Meteor.isServer) {
2.   Meteor.publish('complexPub', function publishFunction(params) {
3.   var selector = ... // complex calculation
4.   return Collection.find(selector, {sort: ..., limit: ...});
5. });
6.  
7. if (Meteor.isClient) {
8.   Meteor.subscribe('complexPub');
9.   Template.foo.complexRecords = function () {
10.     var selector = ... // complex calculation, may be even more difficult to perform on the client
11.     return Collection.find({}, {sort: ..., limit: ...});
12.   }
13. }

Can this be avoided? One obvious mechanism is to add a "publication tag" to the records before publishing them, but that involves needless writing to the database.

It seems that Minimongo should know the publication source of each record. Can this information be exposed to the client?

[Tom Coleman]

I think the answer is:

Not automatically because the data goes through the merge box and over DDP, so by the time it arrives on the client, a single record may have come from various subscriptions (if they supply different fields), and there’s no way to tell anyway.

The best solution I know of is to essentially do as you suggested, but without writing to the database — either add a “psuedo” field to your records via `this.changed` (in the publish function), or--probably better—publish “result sets” into a non-mongo backed collection on the client.

I’ve been planning on writing a blog post about this for some time. Will hopefully do it soon ;)

P.S. in general it’s not possible to find the selector on the client (for example if you are querying a search index). So it’s a very real problem.

Tom

--
You received this message because you are subscribed to the Google Groups "meteor-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to meteor-core...@googlegroups.com.
To post to this group, send email to meteo...@googlegroups.com.
Visit this group at http://groups.google.com/group/meteor-core.
For more options, visit https://groups.google.com/d/optout.

[Pieter Soudan]

I wrote a blog post about this pattern: Query Collection.

These are client-side collection representing the resultset of a query:

http://meteorpatterns.com/Sewdn/query-collections

Pieter

[Andrew Mao]

When I was at MDG, Glasser imagined that a future version of pub/sub would (1) get rid of the merge box and (2) tag documents by which subscription they came over.

If this works, it would both solve the cpu/memory hogging problem that the merge box currently has and make it easier to get the results for one particular subscription.