On 09/02/2009, at 10:50 PM, Damien Katz wrote:
Antony, those sounds like interesting ideas, and I hope you can get
it working. But a one-way replicable db with full-consistency
guarantees is not what CouchDB was ever intended to be (to be clear,
this is a statement of fact). I don't disapprove of it, but it
doesn't fit with CouchDB's design. I'm also not convinced of the
utility of it in the general case, the one-way replication
limitation to me doesn't solve interesting problems, but that's just
my opinion.
I agree that this isn't an interesting problem. However CouchDB sans
replication, or with on-way replication, is a great 'database', with
very useful characteristics, so it would be good if it was easy to use
even for these uninteresting, but *still* potentially game-changing
scenarios. And having said that, even though neither you nor most
others on this list (nor I) would find these CouchDB use-cases
interesting in themselves, my clients are very excited, and the
applications that CouchDB makes feasible, can be interesting.
But that's neither here nor there, the issue is your current proposal,
to whit ...
I'd still like to see the ACID bulk_docs operation preserved, rather
than explicitly removed, because I'm still convinced of the usefulness
of that as a programming API for a number of use-cases.
And if my assumption about the ordering of replication records is
correct, I'd like to see a commit # in the rev because that enables
replication that would preserve an ACID bulk_docs contract in
exclusive replication scenarios.
Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
One should respect public opinion insofar as is necessary to avoid
starvation and keep out of prison, but anything that goes beyond this
is voluntary submission to an unnecessary tyranny.
-- Bertrand Russell
