0

If I have a subscription that does 

Meteor.publish("mypublish", function (status) {
    var foundOnServer = MyCollection.find({"status": status}, {fields: {_id: 1, status: 1, "name": 1}});
    return foundOnServer;
  });

and I'm displaying those records in a table, then I want to let the user click on one of them to bring up the full detail of the record, and now I want to display some more fields that weren't previously published to the client, like maybe address, city, state, etc... how do I code things so that I can get the new fields picked up and put into the local minimongo collection, considering the record is already in the client. Doing a Find just returns the document already in the client, without the extra fields I want.

EDIT: I was not aware of the DDP limitation in that once you subscribe to a field in a nested structure, you are unable to then add more fields from that level of the nested structure. https://github.com/meteor/meteor/issues/998

Stennie
  • 63,885
  • 14
  • 149
  • 175
Wes
  • 826
  • 9
  • 18

1 Answers1

0

Write another publish function for the appropriate subset and return more/all of the the fields. For example:

Meteor.publish('singlePost', function(postId) {
  check(postId, String);
  return Posts.find(postId);
});

When you click on a post, you can subscribe to singlePost which will send all of the fields for that post. The key insight is the documents will be merged on the client.

So if the client had {_id: 'x', message: 'hello'} already in minimongo, and you later publish {_id: 'x', color: 'blue'}, the client will then have {_id: 'x', message: 'hello', color: 'blue'} in its database.

David Weldon
  • 63,632
  • 11
  • 148
  • 146
  • that's what I understood as well from reading tutorials on the subject, however, it isn't happening for me, and it must be something wrong with the way I'm doing things. I put together a meteorpad... if you have time, could you look at it please and see what I'm doing wrong. I tried to make it as simple as possible. If the instructions are in your way on every page, just comment them in the layout template http://meteorpad.com/pad/xKnuw38ce64xCcqbR/DemoDrillDown – Wes Apr 20 '15 at 19:45
  • I can't look at it in detail right now, but I see you are publishing nested fields which makes for problems like the one you are describing. See [this question](http://stackoverflow.com/questions/28969223/one-publication-is-hiding-nested-fields-from-another-publication) and let me know if that helps. – David Weldon Apr 20 '15 at 19:50
  • as a quick test, I removed the demographics nesting and it does work fine now. But flattening out my entire document isn't viable, so I still need to try the solutions you referenced. Thanks! – Wes Apr 20 '15 at 19:59
  • Wow, thanks again for finding this issue. It is not very clear in the docs! I'm not understanding the workarounds I've found so far but hopefully I can make something work, because I cannot afford to pull the whole set of fields up on the client when showing the summary lists. – Wes Apr 20 '15 at 21:13
  • gosh, it seems there should be a way to "drop" the document you're holding on to (the one with the limited set of fields) and then re-fetch (resubscribe/ re query) the full document you want with all the fields. – Wes Apr 20 '15 at 22:08
  • I think lots of implementations are _possible_, but this probably isn't a common enough issue for a large rework of the DDP internals. I'm guessing this isn't going to change anytime soon. Is changing your schema an option? – David Weldon Apr 20 '15 at 22:13
  • I'm evaluating whether I can migrate an old system that was using XML documents in oracle, and right now, I have just done a direct xml -> json mapping. Given this new discovery, I will have to manually flatten out my json doc. Not what I wanted to do but necessary for performance, because I can't be pulling up whole subdocuments until the user goes into the detail screen. – Wes Apr 21 '15 at 03:24
  • I found a workaround that was pretty easy to implement: Number 5 in this explanation http://stackoverflow.com/a/18880927/2799545 This effectively lets me create a "view" so I can have 2 separate publications, one that will have the limited set of fields, and another that will just be used when drilling into detail. – Wes Apr 21 '15 at 15:00