Multiple Cursors - Same Collection?

[peerlibrary]

Multiple Cursors - Same Collection?

[mitar]

Yes, I think it should work to the same extend it works in non-reactive publish. But I am not sure if works there as you would expect (merging fields from multiple cursors). I think it works that the last published document version wins.

Now that I think, are you sure that works even in non-reactive publish?

[dpatte]

Meteor docs says it doesn't work in non-reactive publish, but it does seem to work in other reactive publish packages. Maybe its just the last published document that wins in all packages - as you say. I'll check it out.

[dpatte]

lepozepo:reactive-publish supports returning multiple cursors from the same collection, but I am trying to find a replacement because it has issues with meteor 1.2.
but this library acts like the meteor core publish function in that it doesn't support returning multiple cursors from the same collection.

[mitar]

but this library acts like the meteor core publish function in that it doesn't support returning multiple cursors from the same collection.

What happens if you try to do that?

And yes, I think it is ill defined the behavior if you return multiple cursors from the same collection, so I do not it is really a good direction to try to support that?

[dpatte]

I have found a way to split my publications so that they no longer return multiple cursors per collection in any individual publication. Meteor docs says that in this case, it will merge the results of multiple subscriptions, and it does.
I will leave this as an enhancement request for your package, and I'll open a separate ticket for my current reactive issues with your package.

[mitar]

Yes. Meteor merges per top-field. But be careful, if two publications publish the same top-field for the same document, then there is no defined order in which Meteor will choose the top-field. Often it does not matter (the value of the top-field is the same) though.

I do not think it is a viable feature and it is a known limitation that you should not be publishing the same collection multiple times (it is even documented in warning), so I will for now leave this closed. If somebody makes a simple pull request which makes it work, I would consider it. My main issue is that it is unclear what would be a good semantics. Merging fields together?

Hmm. Now that I am thinking, maybe there is a reasonable approach. Do you know how to test a branch if I make one? We could remember which fields are published with added, not just which documents, and then just at the end of the computation run remove those fields which were not added this time. But otherwise we would simply stack them together (which we can do because we in fact simply call changed instead of added anyway).

BTW, you can publish multiple collections by returning them in multiple autorun:

Meteor.publish('foo', function () {
  this.autorun(function (computation) {
    return Post.find({foo: 1});
  });
  this.autorun(function (computation) {
    return Post.find({foo: 2});
  });
});

[dpatte]

Thanks for your input. Meteor seems to merge the fields of matching docs. This is particularly handy for my use case where I am pulling different fields based on the user's role. Though I shouldn't need it now in your publish as I have split them into separate publications now.

[mitar]

BTW, why don't you build the fields in advance and then do only one query?

[dpatte]

i need different fields from different records of the collection based on their relationship - for privacy reasons.

[mitar]

Yes, but you could compute which fields you need once, no? Can you show me an example?

[dpatte]

This is a sample of what I was using in meteor 1.1 which was working for me using lepozepo:reactive-publish

Meteor.reactivePublish('family',function() {
  return [
    Family.find({ownerId:this.userId}),
    Family.find({ownerId:{$in,related(this.userId)}, private:{$ne:true}})
  ]
}

related() is a function that computes the ownerIds of relatives of the current user. The current user is not permitted to see docs marked private by other users.

lepozepo's package worked great in 1.1, but crashes in 1.2 (with no method 'onStop') - which is why I tried your package instead.

[mitar]

So why don't you do:

Meteor.publish('family', function() {
  this.autorun(function (computation) {
    return Family.find({$or: [
      {ownerId: {$in: related(this.userId)}, private: {$ne: true}}
    ,
      {ownerId: this.userId}
    ]});
  });
});

[mitar]

So I do not think there are many use cases where you would need to publish multiple cursors for the same collection. I think you can always convert it to one query. And it is probably even more efficient so.

So I implemented a check which currently prevents publishing multiple cursors for the same collection name.

[dpatte]

Thanks for showing me the merged query. I'm not sure how to convert it to one query when requesting different fields, though. I do have a few of those which I have split into separate publications.

[mitar]

OK, so, this prevents things only when you are returning cursors and are expecting the publish framework to publish those cursors. You can always observe cursors yourself and do whatever you want. :-)