How does Meteor handle record conflict resolution?

For my project I need a deep understanding of how Meteor handles conflict resolution at the record level.

Does it use OT, diff-merge or something simpler like last edit wins?

If it helps, the problem i’m trying to solve is: In my scenario I will have multiple users (~10) subscribed to the same collection record. The record could be a complex JSON structure. In its basic form, the structure represents a deck of cards like a Trello list - except in my case the deck has parent (group) and child cards. Each user may make non-trivial changes to the deck (i.e. change the sequence of the parent cards (thus moving all children) as well as changing details of each child card. In this case. how will Meteor behave if multiple users change the sequence of cards at the same time?

Thanks :smile:

Last write wins. I’d be tempted to put the cards in a separate collection.

It’s up to the database. In the case of Mongo, last update wins. See after min 38 of (I recommend watching the entire thing though).

1 Like

Last update + top level only.

For example, you cannot have two different clients editing two different subtrees of a doc at the same time because meteor’s built in reativity is based on top level document property changes.

Couple this with last write wins strategy.

For your case, you’ll either need to implement OT (I remember some packages on atmosphere around the concept) or separate your documents into different collections in a pseudo-relational manner.

1 Like

Thanks for all the great replies.

To reduce conflicts, i’ll follow your advice of splitting my JSON object up so it can be stored across multiple MongoDB collections. Anyone care to recommend a package to handle reactive joins?

@serkandurusoy Does this apply to LiveQuery and LiveDB? So basically if we want reactive collections / views, we should only store 1-level JSON in our collections (i.e, no child objects or arrays).

After watching the video @manuel posted, i’m really unsure where OT would need to be applied in the Meteor Architecture. Anyone have any ideas?

I find very easy to use. It is also efficient and stable.

Regarding reactivity, what I ment was, if you change something somewhere below the first node, meteor will assume you have changed the entire document and rerun computations. This becomes problematic where you display subtrees of your document.

For example if you display a post and its comments, where comments are embedded into the post, if a comment gets updated/insert/deleted, the whole post will get reloaded, even in places where you just display the post without its comments.

Normally, you would not need OT unless you need two people editing the same node of the same document at the same time. Like a collaborative text editor.

I understood that it has very simple conflict resolution the “database is always right”. @debergalis talks about it here -

It is for incoming data (find conflicts) but for updates, last writes do always win since they don’t necessarily read the document before the update and do some locking.