[SOLVED] Two publications adding to the same document are overriding each other

help
1

I stumbled upon something I thought I understood, but I clearly don’t.

Meteor.publish('users-counts', function(username){
	var fields = {
		'username':1,
		'profile.writtenAboutCount':1,
		'profile.authoredCount':1,
		'profile.followingCount':1, 
		'profile.savedCount':1, 
		'profile.followers':1
	}
	return Meteor.users.find({username: username},{fields: fields})
})

Meteor.publish('users-profile',function(username){
	var fields = {
		username:1,
		'profile.name':1,
		'profile.location.coordinates':1,
		'profile.score.up':1,
		'profile.tags':1,
		'profile.body':1
	}
	return Meteor.users.find({username:username},{fields:fields})

})

When I go to some pages, I only need users-counts, which justifies decoupling the subscriptions. When I go to the profile page, I need ALL of the data, so I subscribe to both users-counts and users-profile. But when I check to see what the server sent down, it only sent down the fields published by users-profile.

A fix might be to just publish all of the data in users-profile also, but keep the users-counts for when I only need the counts data. But, if I already publish users-counts before, then wouldn’t that be a waste? I am pretty sure Meteor checks the server cache for that connection and only sends down diff-ed data, so it might not be a waste.

Any clarification or help would be appreciated.

Thanks!

2

This is a classic problem with the Meteor pub/sub model. First level fields from separate publications are cleverly integrated, but nested fields are not. See this issue.

When I had to deal with this, I just ended up solving it in the most inefficient way possible by overpublishing a crapload of nested data for some scenarios, just to make sure it was there for others. I’m still looking for a good pattern to work around this.

3

@babrahams yikes! That’s exactly what I ended up doing. But I think I might just top-levelify everything by bypassing the user.profile.

Nesting isn’t mission critical for me, thankfully. It’s because of this silly “profile” construction…

That’s quite unfortunate, though. Intuitively, one would expect it to work. Thanks for your reply. :smile:

4

Yes, I’ve learnt from that experience to keep everything as top-level as possible and just prefix field names rather than nest in subdocuments.