[Couchdb Wiki] Update of "HTTP Document API" by DavidVanCouvering

[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 DavidVanCouvering:
http://wiki.apache.org/couchdb/HTTP_Document_API

------------------------------------------------------------------------------
  }}}
  
  Note that CouchDB will return in the response an id and revision for every document passed as content to a bulk insert, even for those that were just deleted.
+ 
+ == Transactional Semantics with Bulk Updates ==
+ 
+ In previous releases of CouchDB, bulk updates were transactional - in particular, all requests in a bulk update failed if any request failed or was in conflict. There were a couple of problems with this approach:
+ 
+ - This doesn't actually work with replication. Replication doesn't provide the same transactional semantics, so downstream replicas won't see "all-or-nothing" transactional semantics. Instead, they will see documents in an inconsistent state until replication of all documents involved in the bulk update completes. With bidirectional replication it can get even worse, because you can get edit conflicts that must be fixed manually.
+ 
+ - If your database is partioned (aka "sharded"), different documents within the transaction could live on different nodes in the cluster, and these kinds of transactional semantics don't work unless you use heavy, non-scalable approaches like two-phase commit.
+ 
+ With release 0.9 of CouchDB, transactional semantics have been changed to make sure CouchDB works consistently in single-node, replicated and partitioned environments. There are now two transactional models supported:
+ 
+    * *non-atomic* (default) - some documents may successfully be saved and some may not.  It is up to the application to check that all documents were successfully saved/updated.
+ 
+    * *all-or-nothing* - either all the documents will commit successfully or none will. However, it does not do conflict checking, so the documents will be committed even if there are conflicts. Conflicting versions of the document will be saved. 
+ 
+ - non-atomic - In this mode, 
  
  === DELETE ===