couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antony Blakey <>
Subject Re: Transactional _bulk_docs
Date Fri, 06 Feb 2009 03:02:51 GMT

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  

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

View raw message