On 26/01/2009, at 8:33 PM, Jan Lehnardt wrote:
On 24 Jan 2009, at 21:37, Matt Goodall wrote:
2009/1/24 Matt Goodall <[email protected]>:
Hi,
I'm a bit confused why this was closed. Perhaps a description of the
"new behaviour" is available somewhere?
The only mention of anything related to a change in _bulk_docs I've
*noticed* is about not failing everything in the list of updates
(might be nice if that was optional, actually) and the associated
error reporting. However, that doesn't necessarily fix the problem I
described.
Actually, I think I misunderstood the change. It seems it's only to
say what document failed, i.e. better error reporting, in which case,
a) the change sounds good, b) there is nothing to make optional, c) I
still don't think it addresses the issue. Please correct me if I'm
wrong!
We can't sensibly make bulk requests with database partitioning
over multiple nodes. Damien talked about changing the bulk request
behaviour also for single-nodes to avoid confusion. If I understand
correctly, bulk writes then work a lot like replication, in that your
data gets written in any case but might cause conflicts and you
can find out where conflicts occurred using a view checking
the `_conflicts` member of a doc.
What about uses that don't require database partitioning? Why remove a
feature useful for a particular use case? You could add a new feature
that implements this kind of functionality in a partitioned database,
and either return some kind of error from _bulk_docs. This change
makes it a lot more complicated for the client to deal with, and it's
forcing everyone to pay for a feature that only some may use.
Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
Some defeats are instalments to victory.
-- Jacob Riis
