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 damien
Date Fri, 27 Mar 2009 13:50:32 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/HTTP_Bulk_Document_API

------------------------------------------------------------------------------
  
  In this case, all three documents will be saved, and the response will show success for
all of them. However if the document with id 0 had a conflict, both versions will be present
in the database, with an arbitrary choice made as to which appears in views. You can check
for this status using a GET with {{{?conflicts=true}}}
  
- All your updates will always be accepted - even if you give a non-existent _rev - so the
term "all or nothing" really only applies to what happens in a crash scenario. (FIXME: is
the all-or-nothing transaction guaranteed across replication too?)
+ All your updates will always be accepted - even if you give a non-existent _rev - so the
term "all or nothing" really only applies to what happens in a crash scenario.
  
+ All or nothing transactions should not be used to enforce referential integrity, as some
or all updated documents might become losing conflicts during the update. The transaction
should be used to make sure all information is captured in an atomic operation, but conflicts
may need to be addressed later. Applications that rely on this functionality should be able
to tolerate some documents missing or being in a conflicted state until conflict resolution
can occur.
+ 
+ Bulk updates work independently of replication, meaning document revisions originally saved
as part of an all or nothing transaction will be replicated individually, not as part of a
bulk transaction. This means other replica instances may only have a subset of the transaction,
and if an update is rejected by the remote node during replication (e.g. not authorized error)
the remote node may never have the complete transaction.
+ 
- However, note that POSTing a single document with {{{"all_or_nothing":true}}} behaves completely
differently from a regular PUT, since it will save conflicting versions rather than rejecting
a conflict.
+ Note that POSTing a single document with {{{"all_or_nothing":true}}} behaves completely
differently from a regular PUT, since it will save conflicting versions rather than rejecting
a conflict.
  
  {{{
  $ DB="http://127.0.0.1:5984/tstconf"

Mime
View raw message