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_Bulk_Document_API" by JensAlfke
Date Thu, 08 Dec 2011 01:37:38 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Couchdb Wiki" for change notification.

The "HTTP_Bulk_Document_API" page has been changed by JensAlfke:
http://wiki.apache.org/couchdb/HTTP_Bulk_Document_API?action=diff&rev1=13&rev2=14

Comment:
Added documentation of new_edits:false mode to _bulk_docs.

      {"id":"2","rev":"2-3978456339"}
  ]
  }}}
+ 
+ 
  === 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:
  
@@ -145, +147 @@

  {"_id":"person","_rev":"2-3595405","name":"jim","_conflicts":["2-2835283254"]}
  }}}
  
+ === Posting Existing Revisions ===
+ 
+ The replicator uses a special mode of {{{_bulk_docs}}}. The documents it writes to the destination
database already have revision IDs that need to be preserved for the two databases to be in
sync (otherwise it would not be possible to tell that the two represent the same revision.)
To prevent the database from assigning them new revision IDs, a {{{"new_edits":false}}} property
is added to the JSON request body.
+ 
+ Note that this changes the interpretation of the {{{_rev}}} parameter in each document:
rather than being the ''parent'' revision ID to be matched against, it's the ''existing''
revision ID that will be saved as-is into the database. And since it's important to retain
revision history when adding to the database, each document body in this mode should have
a {{{_revisions}}} property that lists its revision history; the format of this property is
described on the [[HTTP_Document_API]] page under "Accessing Previous Revisions". For example:
+ 
+ {{{
+ $ curl -X POST -d '{"new_edits":false,"docs":[{"_id":"person","_rev":"2-3595405","_revisions":{"start":2,"ids":["3595405","877727288"],"name":"jim"}]}'
"$OTHER_DB/_bulk_docs"
+ }}}
+ 
+ This command will replicate one of the revisions created above, into a separate database
{{{$OTHER_DB}}}. It will have the same revision ID as in {{{$DB}}}, {{{"2-3595405"}}}, and
it will be known to have a parent revision with ID {{{1-877727288}}}. (Even though {{{$OTHER_DB}}}
will not have the body of that revision, the history will help it detect conflicts in future
replications.)
+ 
+ As with {{{_all_or_nothing}}}, this mode can create conflicts; in fact, this is where the
conflicts created by replication come from.
+ 

Mime
View raw message