[Couchdb Wiki] Update of "Transaction model use cases" by AndriusJuozapaitis

[Apache Wiki <wi...@apache.org>]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Couchdb Wiki" for change notification.

The following page has been changed by AndriusJuozapaitis:
http://wiki.apache.org/couchdb/Transaction_model_use_cases

------------------------------------------------------------------------------
  
  DVCS: I may as well throw this one out there -- it seems like an obvious use case for a document-oriented db in general and Couch in particular. Given the constant arguments over the available choices there's clearly no _winner_ yet, so what the hell -- why not in Couch? The only way I can imagine an implementation with the current transaction semantics is to keep each branch as a document and drop docs in as attachments, but this is probably less than optimal. Correct me if I'm wrong.
  
+ --
+ I'm trying to model a simple shopping cart solution on couchdb, just to find out the solutions to the problems that have come to my mind so far. Let's say, I have 2 types of documents, products and categories, where product may belong to multiple categories. I expect product to hold an array of category ids. A simple use case:
+ 1) user A updates an existing product, and updates a category(-ies), say, increasing product count property
+ 2) the same category at the same time is being updated by user B, by uploading an updated image to it
+ 
+ If the operations happen in this exact order (1,2), user B will get a
+ concurrent modification warning, and will have to reapply his changes.
+ 
+ But what if the product gets updated, then the category gets updated with a new image, and then the product count is increased on that category? The last step will fail, and the data in the system will remain in (logically) inconsistent state. 
+ --
+