Nested subdocuments a bad idea?

1

Hi

I have heard that Meteor is only able to pick up reactive changes on the top-level document fields in a collection.

Does this mean that it’s better to never nest documents?

2

Generally speaking MongoDB tends to prefer denormalized document structures. What does that mean? Well take for example this post and its comments. The more “SQL” approach is to do it like this:

{
  "title": "Nested subdocuments a bad idea?",
  "content": "There is content here",
  "authorId": "tarlen'sId",
  "comments": [ "myCommentId" ]
}

Instead, it’s better to structure it a bit more like this, and normalize on writes rather than reads.

{
  "title": "Nested subdocuments a bad idea?",
  "content": "there is content here",
  "authorId": "tarlensId",
  "comments": [{
    "authorId": "myId",
    "content": "don't do it matey!",
    "when": new Date
  }]
}
1 Like
3

My question was more aimed whether or not it’s true that Meteor doesn’t pickup reactive changes in nested subdocuments. Not whether or not to normalise data

1 Like
4

Yes. Check this out:

This is what checks for changes to the documents. The livedata server (part of ddp server) is what’s responsible for this.

1 Like
5

So… we shouldn’t EVER use subdocuments if we wish to utilize reactivity?

1 Like
6

I guess it depends on the frequency of updates on the subdocuments. If there are going to be frequent inserts/updates to the subdocument array, steer away from it. Otherwise, why not.

7

There is no reason you can’t. When a sub-document is modified, basically meteor recognises the change and sends the entire document to the client. My hope is that the mdg @sashko improve this and only patch deltas.

I have used a mix of the 2 approaches. Subdocuments in our case are a way to overcome the lack of transaction support in mongo. For example, imagine you have an array of documents that the user expects to sort. Persisting their sort changes with a single document that contains an array of sub-documents will be atomic (last write wins). If instead you wanted to split the sub-doc array into a child collection…without mongo transactions, you can’t guarantee integrity in a concurrent user environment.

Hope this helps

8

@dcworldwide: This is a trade-off. Deep-diffing documents costs much more than top-level diffing. So it might optimize how much data is transferred over the wire, but then you have a bigger load on the server and higher latency. Also subdocuments tend to be smaller, so there is not really so much more data going over the wire often, especially with compression available in Meteor 1.2.

So I think trade-off is good for a general case. I think adding more complexity would make things worse. And as a data consumer you can always use fields parameter to find call to limit which subdocuments you are interested in and in this way limit what you get as data and what is reactively dependent. But what is send over the wire is probably not so important and is good as it is.

2 Likes
9

Sounds like you guys have given this a fair bit of thought. Thanks

10

Honestly I don’t really care that much about nested documents, I just find it weird that MongoDB is supposedly all about nesting stuff, and that Meteor doesn’t fully support it. If I had known this from the start I would obviously have kept everything flat…

11

I have an app where about 25% of my development time was spent trying to figure out how to make meteor play nicely with sub documents. It was the first time I started to miss SQL, because although I saved a bit of time being lazy and not thinking too hard about my schema, reactive updates to subdocuments felt incredibly messy and ad hoc.

12

How well Meteor supports nested documents reactivity these days? I have built my application at top-level mongo documents, but I recently started to re-created my app in a nested way, cause this way I could mitigate subcriptions and I like the way I can parse my nested documents in JavaScript arrays…however I have to stop if Meteor does not support nested arrays reactiviness…