On Mar 13, 2009, at 11:12 AM, Tim Parkin wrote:
Wout Mertens wrote:
On Mar 13, 2009, at 10:54 AM, Tim Parkin wrote:
The current arguments against bulk docs are against it's
atomicity. I
would be reasonably happy to have a bulk docs that wasn't atomic but
allowed some from of 'remove the changes applied so far'
functionality.
So out of interest, to get into the nitty gritty details, is this the
problem? The fact that CouchDB handles one document at a time and
can't
remove a change?
<snip>
Wout.
I think all bulk doc changes were written somewhere and then only
switched in once the last was successful.. so no locking.
With the new bulk docs, you could apply bulk doc change, find out the
last one was wrong and then discover that all but the last one had
already been replicated..
There is an all_or_nothing option for bulk updates, it does validation/
security checks on the documents, and if all pass then it saves all
the documents. If there is a failure or db crash during the commit,
none of the documents are saved. However, it does not check for
conflicts, documents are saved regardless if the conflict.
You can do all or nothing bulk updates with conflict checking by
serializing updates at the app level (or use a programmable reverse
proxy) and check bulk updates before committing to see if they'll
conflict. With the all_or_nothing flag, you'll get exactly the
behavior you desire.
-Damien
