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 "HTTP Document API" by DavidVanCouvering
Date Mon, 23 Mar 2009 13:48:11 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 DavidVanCouvering:
http://wiki.apache.org/couchdb/HTTP_Document_API

------------------------------------------------------------------------------
  
  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.
+    * 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 partitioned (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.
+    * If your database is partitioned (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.
+    * '''non-atomic''' - This is the default behavior.  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* - To use this mode, pass "all-or-nothing" set to true in the request
(e.g. ''/{dbname}/_bulk_docs?all-or-nothing=true)''.  In this case 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.  If any documents have a conflict, then in
the response that document will show a conflict error, for example
+    * '''all-or-nothing''' - To use this mode, pass "all-or-nothing" set to true in the request
(e.g. ''/{dbname}/_bulk_docs?all-or-nothing=true)''.  In this case 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.  If any documents have a conflict, then in
the response that document will show a conflict error, for example
  
  {{{
  {

Mime
View raw message