couchdb-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <>
Subject [Couchdb Wiki] Update of "Transaction model use cases" by AndriusJuozapaitis
Date Thu, 09 Apr 2009 10:43:31 GMT
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:

  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. 
+ --

View raw message