Atomic bulk docs is in the patch, it just doesn't do conflict
checking. If any docs are conflicts, they are saved anyway as
conflicts. This means it's really for message queue functionality, not
database consistency, your data is safe and committed but might not be
immediately available or consistent between docs. The reasons we are
removing all or nothing with conflict checking as it doesn't work with
replication (both offline and clustering) as docs are not replicated
in a single transaction or even in update order. And getting it to
work with partitioning would cause unacceptable write performances. If
we leave it, people will rely on the behavior not understanding it
doesn't really work with the rest of CouchDB.
So if you are currently using bulk docs to guarantee inter-document
consistency, it already doesn't work with replication. It only works
on a single machine, so no master-slave and no hot stand-by setup
would work as neither are guaranteed to be in a consistent state at
any point.
-Damien
On Mar 12, 2009, at 8:17 AM, Tim Parkin wrote:
Hi,
I noticed a commit that suggests "atomic" bulk docs will no longer be
working on trunk. Is now the right time to discuss the possibility of
keeping a version of "atomic" bulk docs somewhere in couchdb rather
than
removing the functionality?
I think I understand that there is a philosophical reason for not
having
it in (I think the reasoning is "don't have features in couchdb that
won't work distributed" but I may be wrong ) but I personally am of
the
opinion that trying to hide the difference between a single couchdb
and
network of couchdbs at the cost of removing functionality that has
legitimate use is not a good idea.
Anyway - I don't want to start a thread prematurely but also didn't
want
to miss adding my opinion. I'm happy to hang fire on discussion until
later though..
Regards
Tim Parkin
