Meteor.publish: publish collection which depends on other collection
Asked Answered
S

2

17

I have a publish function as follows:

Meteor.publish('tasks', function (name) {
    var project = Projects.findOne({name: name});

    return Tasks.find({projectId: project._id});
});

Now assume that at some point changes are made to Projects with the result that the above Projects.findOne returns a different project and so the Tasks.find will return other tasks. However the changes made to Projects doesn't republish the tasks

I've used reactivePublish, but it turns out the package has issues (and also does not have any unit tests). So, is there an easy way to make this publish function re-publish when project changes ?

Stepmother answered 16/10, 2014 at 7:48 Comment(8)
possible duplicate of Publish documents in a collection to a meteor client depending on the existance of a specific document in another collection (publish-with-relations)Stallfeed
Why should you republish it? The cursor you return is Tasks. If you Tasks is changed, it should be automatically published.Huberman
I was actually looking for an answer without the use of some kind of plugin. For example, the answer in the other post suggests to use meteor-publish-with-relations This project was last modified a year ago. It will probably give me at some point the same issues I have now with reactivePublishStepmother
what are you subscribing to? Does the name change reactively in your subscribe?Spec
good point, it wasn't very clear. I've improved the questionStepmother
I'm not sure it will work (so I'm not posting it as an answer), but have you tried wrapping the findOne in a Tracker.autorun?Spec
Never heard of Tracker, seems like a replacement of Deps, is it ? Furthermore, Tracker seems to only work on the client!Stepmother
You should be able to get this done using the added/changed/removed interface for publish. See the second, long example in the documentation for publish.Spec
S
23

Overview

As of this writing, reactive joins are an unsolved problem. For a complete overview see Reactive Joins In Meteor.

Recommendations

I strongly recommend against using observeChanges directly. It's incredibly hard to get right, and easy to develop a memory leak. If you don't believe me, watch this video on EventedMind. It will make your eyes bleed.

There are several package-based solutions to this problem. The meteor guide recommends publish-composite.

If you find the idea of using a package-based solution to be unacceptable, have a close look at the Joining On The Client section from Reactive Joins In Meteor. It's clean but requires more waiting on the user's part. Also see my post on template joins if you prefer to active your subscriptions at the template level.

Stallfeed answered 17/10, 2014 at 8:54 Comment(4)
The problem with the available packages is that they have issues or no documentation (not to mention unit tests). So until this is part of meteor I'll fix it on the client. Thnx!Stepmother
The code in the Reactive Joins in Meteor article seems to have gone stale with changes to iron-router's API. Is there any way we could get a code snippet that works in current versions?Otisotitis
In the meantime, smart-publish has advised to avoid using it in production. Looks like reywood:publish-composite is the leader nowadays.Orvas
Yes, I've been meaning to update this answer. Thanks Dan.Stallfeed
W
6

There is a new kid on the block now. A full server-side reactive publish solution. (Disclaimer: I am one of the authors.) It is designed so that you can use it normally as you would expect with autorun. It takes care of everything automatically.

Install the package by calling meteor add peerlibrary:reactive-publish.

With the package added you can then simply do:

Meteor.publish('tasks', function (name) {
    this.autorun(function (computation) {
        var project = Projects.findOne({name: name}, {fields: {_id: 1}});

        return Tasks.find({projectId: project._id});
    });
});

Exactly as you would expect. :-)

The important part is to limit fields in the first query only to _id, otherwise autorun will be rerun every time any field of the project document changes. You do not want that.

Waxwork answered 3/10, 2015 at 8:58 Comment(3)
Thanks a lot for sharing!Stepmother
doesn't work for me, maybe it got removed in Meteor 1.3Londonderry
You have to use the package linked above.Waxwork

© 2022 - 2024 — McMap. All rights reserved.