couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wout Mertens <wout.mert...@gmail.com>
Subject Re: Bulk Docs - 'remove changes so far' Functionality?
Date Fri, 13 Mar 2009 14:17:43 GMT
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?

I think that I see why this is such a problem. If you provide rollback  
(or simple rewrite-prev-version) functionality, it impacts  
replication. You can only replicate changes up to the last seq before  
an unfinished bulk update started, otherwise a non-confirmed document  
might slip through. So if you have back-to-back bulk updates, there's  
no window for replicating.

Is this correct? If so I don't see how bulk_docs can be atomic within  
the spirit of the charter of CouchDB.

In fact, I wonder how it worked up to now. Suppose there is this  
sequence of updates: (Docs are ABC, revs 123)

1. DB has A1 B1 C1
2a. Update: B2
2b. Bulk update: A2 B2
3. GET A

If 2a is handled first, the bulk update 2b should fail. How can you be  
sure that in 3, A returned is then A1? I suppose you need to use a  
lock, which makes performance unpredictable.

Wout.

Mime
View raw message