Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Mongo DB: quick questions about conflicts

 
Marcus Kelvin
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I really like couchdb because of the JSON document format and js/http interface, but had never heard of mongodb, which was a nice surprise -- not just one but two such entities! (At least WRT to the js stuff)

I just spent a few minutes reading the tutorial and glancing thru the manual. I notice mongo appears to use the same default UUID doc _id. Is that flexible? Ie, can the ids be created manually?

I also notice that mongo does in place updates of single fields (whereas couch just replaces an entire document). There is an obvious advantage to that in terms of reducing possible conflicts, but it would also make actual conflicts harder to resolve. So, with couch, each update updates a second UUID, the _rev field; this is included when the document is selected, and because the entire document must be replaced for any update, if the _rev field of the replacement does not match the current one in the database, the update is rejected. This makes it easy to prevent a scenario where two users are viewing the same document, then one updates something unbeknownst to the other, and then the second user unwittingly overwrites the changes made by the first.

For example: we are both viewing the same post. Let's say the paragraph above is a single JSON field in the db, and I edit that paragraph here, removing a sentence and sending the updated paragraph back to the server. Meanwhile, you edit the same paragraph differently. If your update is subsequent to mine and no conflict is thrown, the sentence I just removed will be back again.

The _rev field alone is not a complete solution to this -- it would be very unfriendly to just throw back "Sorry, too late!" to the second user -- but it is a decent starting point. Is there anything paralleling this in mongo, or does handling conflicts begin in the particular interface design?
 
Kyle Banker
author
Greenhorn
Posts: 16
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Marcus,

Yes, you can use any value for _id so long as it's unique.

In MongoDB, there's no multi-master replication and within a single node, all writes are serialized. So conflicts aren't possible. Last write wins.

In your example, whether our writes conflict depends on how you issue the write. If you use $set to set the value of the field containing said sentence, then like before, the last write will win. You can use optimistic locking to prevent one writer from overwriting a concurrent change, as you might do with an RDBMS. MongoDB, like I believe CouchDB, does not support transactions.

Kyle
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic