On 06/02/2009, at 6:20 AM, Chris Anderson wrote:
Antony, maybe it would help for you to explain just exactly what you
wouldn't be able to do, without the bulk docs API. It will help to
inform people about the technical issue.
My original email included this:
-------------------------------------------------------
For example, I have documents that can be cloned. The cloned document
contains a reference to the originating document. Then I delete the
original document, the clone history needs to be updated to remove the
reference to the original document and replace it with an original-
deleted history item. There is a business case that requires this
consistency.
With a transactional API this is easy. Without it, I can't see a way
to maintain consistency in the face of concurrent application access
and/or failure.
-------------------------------------------------------
However, I don't think this is really about a specific example.
The problem is that if you get one side of the relationship written
and visible, but the other side not, then other concurrent accessors
will see a partially successful update.
One response is "but you'll see this problem during replication", but
I think this is making a big assumption about how replication is
managed/interleaved with local application behaviour.
Replication, and dealing with conflicts, is in no way automatic. As
others have stated, there is no domain-independent way of resolving
conflicts. Surely if it were possible to build a transactional API on
top of a conflict-based system, then this statement would not be true?
I am deploying CouchDB like a Notes CLIENT. Not as a high-performance
database server. Replication is an explicit operation, that halts
normal activity. For my first delivery, replicas are read-only, so
replication conflict isn't possible, but when I move to a distributed
writers scenario, resolving replication conflicts will involve a
specialized UI, that allows all conflicts to be resolved before normal
operation resumes. Thus the editing application always sees a conflict-
free database.
The use-case of someone doing a local operation e.g. submitting a web
form, is very different than resolving replication conflicts. Conflict
during a local operation is a matter of application concurrency,
whereas conflict during replication is driven by the overall system
model. It has different temporal, administrative and UI boundaries.
In short, I think it is a mistake to try and hide the different
characteristics of local (even clustered) operations, and replication.
You may disagree, but if the system distinguishes between these two
fundamentally different things (distinguished by their partition-
tolerance), you can code as though every operation leads to conflict
if you wish, but I can't take advantage of the difference.
I know that the long-standing vision of Couch doesn't include special
API exceptions for when you are running on a single node. And I'm a
little afraid that the transactional doc commits Antony wants us to
keep, are only a mirage, which would lead to trouble anyway, when
distributed systems are involved.
I don't understand why this needs to be the case. You can do
transactions in distributed systems. Do you have a model that isn't
amenable to a Scalaris treatment? Especially given that we're only
talking about transactions over a set of processes that are providing
an illusion of a single system. Such a cluster already requires some
degree of partion-tolerance, right? And if not, then what
distinguishes a cluster from a partition-tolerant p2p mesh?
Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
The fact that an opinion has been widely held is no evidence whatever
that it is not utterly absurd.
-- Bertrand Russell
