On 12/03/2009, at 10:47 PM, Tim Parkin wrote:
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..
I agree that hiding the distinction between single-node and multi-node
operation is not a good idea.
However I think this discussion has come and gone, the outcome being
that a) couchdb requires, by design, that no functionality is provided
that cannot be provided under a loosely couple cluster model without
distributed transaction support; and b) therefore, atomic bulk docs
e.g. all-or-nothing-fail-on-conflict will not be provided by couchdb.
I require this functionality, and don't care about *loosely coupled*
clustering, and hence have to maintain a fork that retains this
functionality. This fork cannot be called CouchDB unless it is purely
a point-in-time snapshot from the subversion repository - anything
else is regarded as a derived work by Apache, understandably.
Antony Blakey
--------------------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
Don't anthropomorphize computers. They hate that.
