Second subscription on collection merge with subdocuments won't work?

Hello there,

I read some stuff in the forums of other people who issued the same thing.

Example:

I have an sales app wich contains some information on orders, but on the order detail page
On index view i have an table containing only three fields of the order information:

  • shipping.first_name
  • order_reference
  • orderLines.price

The publication i use for this:
Meteor.publish(“ordersOverview”, function (limit) {
return Orders.find(
{},
{
fields : {order_ref:1,‘shipping.first_name’:1,orderLines.price:1},
limit:limit,
sort: {order_date: -1}
}
);
});

The subscription i use for this:

Template.ordersOverview.onCreated( function() {

this.subscribe('ordersOverview');

});

In the overview page i see the three fields which i needed and subscribed for.

But, when i navigate to the order detail page, i need more information of this order and need all the fields.
The publication i use for this:

Meteor.publish(“orderById”, function (_id) {

return Orders.find({_id:_id});

});

Now i get almost all fields, except some fields from the subdocuments orderLines and shipping.
I do get the requested shipping.first_name and orderLines.price but all the other fields in these subdocuments are missing. The top-level fields are okay and are there.

I read somewhere that this has something to do with mergebox and subdocuments, these won’t merge properly?

What can i do about this?

You are absolutely correct about the mergebox. It will only merge documents on the first level fields. The solution is generally to use a more flat schema.

Oke thats a pitty…
I am using an array to store the order items.
There is no way i can use that in an more flat schema? Should i store those rows in a separate collection and make some kind of join in the publish function?

I think this is not the best way te store this kind of information.

Are there any other options?

Does this happen even if the first subscription is let stop and the new one is subscribed to? AFAIK, you should get all fields sent to the client as long as you aren’t cashing the first subscription, but I could be wrong. As far as flattening out your schema you could use fields such as shipping_first_name. I really don’t think normalization would be super helpful for this particular case.

yes even then it still happening.
With shipping names flattening would not be a problem to like it like that, but with the order items (which is in array with +/-10 fields) it’s not possible to flat it.

It feels like a big failure/bug on Meteor… it’s too bad.