couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antony Blakey <>
Subject Re: couchdb transactions changes
Date Mon, 09 Feb 2009 05:58:38 GMT

On 09/02/2009, at 4:14 PM, Adam Kocoloski wrote:

> A bit more work is required, I think.  In addition to inserting MVCC  
> commit point markers in the replication stream, we'd also have to  
> include all the document/rev pairs that were part of the _bulk_docs  
> update.  As it stands today, if one of those documents is updated  
> again it will only show up at the later update_seq.

Do you mean update in the the same _bulk_docs or in a later update?  
The document revision created in the _bulk_docs will still show up in  
the replication stream - it does now doesn't it? But even if it  
doesn't it doesn't matter because ...

> This could actually get pretty hairy, now that I think of it.  What  
> happens during compaction?  Do we save old revisions of a document  
> if the revision was part of a _bulk_docs update?

No, because the replication is consistent wrt the MVCC commit point  
when the replication starts. I'm not suggesting replicating  
transactions, only that the replication is MVCC-aware.

User-level transactions are orthogonal to replication in this  
scenario. If you expose the MVCC commit point in the user API - which  
is exactly when the previous _bulk_docs did - and make replication  
MVCC aware, then you have all the consistency you need. You don't need  
the history of the transaction to be preserved during replication. You  
only need to ensure that it is possible to replicate a consistent  
source state, where consistent means at an MVCC commit point.

Antony Blakey
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

Isn't it enough to see that a garden is beautiful without having to  
believe that there are fairies at the bottom of it too?
   -- Douglas Adams

View raw message