couchdb-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Couchdb Wiki] Update of "Transaction model use cases" by damien
Date Thu, 09 Apr 2009 11:37:58 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 damien:
http://wiki.apache.org/couchdb/Transaction_model_use_cases

------------------------------------------------------------------------------
  Real world use cases are desired, with enough details as to explain why the transactions
might be necessary, the consequences of not having it, etc. Then we can examine the use cases
and see if the current CouchDB models can work, or if CouchDB is really appropriate, or if
we need new transaction models to support the use cases.
  
  
+ ==DVCS==
- 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 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.
  
- 
+ ==Update Product and Categories==
  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
  
+ ""You shouldn't have a categories count that gets manually updates. Instead, create a "products
by category view" and use a reduction to count the number of each category. -Damien""
+ 
  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. 
+ 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.
  

Mime
View raw message