I just spent a couple of days trying to figure out why I was getting unexpected paging results. I am curious if anyone knows why find from publication is not the default (or at least a standard option)? It seems like that would be optimal instead of having to run into merge issues then locate the fact that this is even available in an obscure blog post somewhere or the brief mention in a paragraph in the Meteor guide.
Is there a situation where one might not want this to be the default behavior?
I can imagine situations where I would like to override it and still use normal find() on the client. But I don’t know situations when I wouldn’t like it to be the default behaviour.
Thanks for writing that, I didn’t know about this package and it seems very handy.
+1 for mentioning this package in the guide, @sashko
I agree that the behavior of standard subscriptions may be unexpected sometimes, but the reason that was done in the first place was to avoid duplication of data on the client. There’s actually a fair bit of work that the server does in the merge box to ensure you’re only getting each document and each update once.
If I remember correctly, find from publication creates different minimongo collections on the client, which is slightly suboptimal, because you might end up storing duplicates of your documents on the client if multiple subscriptions contain the same document.
As to why the option to do find from publication wasn’t built into Meteor from the start: I think it simply wasn’t anticipated that this would be really necessary.
As far as I understand the docs, the created minimongo collection contains only references, such as the id of the document and the name of the publication that returned this data. This metadata may contain documents with same id if they were returned by multiply publications, but it’s only the id reference, not the whole document.
Either is preferable to getting unexpected documents displayed, but I too believe that just references to the subscription are passed, not duplicate documents. The larger issue is how hidden it was that this could happen in the first place and even more hidden the interim solution was.
Getting unexpected data displayed in a real application is never a good thing. The fact that you can seems like it should be in bold red somewhere (along with how to address it). Most of our occurrences are a full collection (paged) from one subscription, and one to ten additional potential duplicate documents from another subscription to the same collection. I’d rather have the 1-10 duplicates hidden on the client then have than to have them display to the user in the wrong places.
My main concern/question is when would you not want this (assuming there are no duplicates).