Changes to foreign keys are not reflected in the published documents

[yeputons]

Here's a gist with demonstration. Create a new meteor project, add publish-with-relations meteorite package and run.

You'll see two collections: A and B. Subscribe to B, select a particular element, unsubscribe from B and update the only existing element A with that new 'B' element. Changes will be applied (and if you open another tab, you'll see them), but subscription to B is not reactivelly updated.

[tmeasday]

Oh, right.

So I think the issue is that you are changing the foreign key on an object. This is of course legitimate, but not a very common thing to do, thus running into a problem with this lib. I'll change the name of this issue.

[tmeasday]

Oh. I can't. Well I wanted to change it to Changes to foreign keys are not reflected in the published documents.

[rlora]

I think I'm having the same issue. I have a collection for Players that is related to Meteor.users through a "_userId" field.

When a player is created, it is invited to join the app, and at the moment of joining the "_userId" field is set to establish the relationship. When this happens, player changes are pushed reactively but the new user is not added to the users collection.

This case is a subset of "changing the foreign key", more like late binding a relationship.

Any chance this could be fixed in the future?

[yeputons]

@tmeasday I think it's because of {reverse: true} filter in this line. However, in this example I use reverse relations and here are steps to reproduce:

1. Create new meteor project
2. Clone gist into it
3. Remove autopublish package
4. mrt
5. Open console
6. B.insert({})
7. Select arbitrary element A and change it's bId to id of the newly created B
8. Change back
9. This A disappeared. If you refresh page, it appears back.