[Couchdb Wiki] Update of "Frequently_asked_questions" by fana

[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 "Frequently_asked_questions" page has been changed by fana.
The comment on this change is: changed some text to bullet points.
http://wiki.apache.org/couchdb/Frequently_asked_questions?action=diff&rev1=25&rev2=26

--------------------------------------------------

  
  The problem you outlined is primarily an inventory issue. If you have a document describing an item, and it includes a field for "quantity available", you can handle concurrency issues like this:
  
- Retrieve the document, take note of the _rev property that CouchDB sends along
+  * Retrieve the document, take note of the _rev property that CouchDB sends along
- Decrement the quantity field, if it's greater than zero
+  * Decrement the quantity field, if it's greater than zero
- Send the updated document back, using the _rev property
+  * Send the updated document back, using the _rev property
- If the _rev matches the currently stored number, be done!
+  * If the _rev matches the currently stored number, be done!
- If there's a conflict (when _rev doesn't match), retrieve the newest document version
+  * If there's a conflict (when _rev doesn't match), retrieve the newest document version
+ 
  In this instance, there are two possible failure scenarios to think about. If the most recent document version has a quantity of 0, you handle it just like you would in a RDBMS and alert the user that they can't actually buy what they wanted to purchase. If the most recent document version has a quantity greater than 0, you simply repeat the operation with the updated data, and start back at the beginning. This forces you to do a bit more work than an RDBMS would, and could get a little annoying if there are frequent, conflicting updates.
  
  Now, the answer I just gave presupposes that you're going to do things in CouchDB in much the same way that you would in an RDBMS. I might approach this problem a bit differently: