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.
