couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kocoloski <>
Subject Re: couchdb transactions changes
Date Mon, 09 Feb 2009 17:41:21 GMT

On Feb 9, 2009, at 12:35 PM, Paul Davis wrote:

> On Mon, Feb 9, 2009 at 11:46 AM, Adam Kocoloski
> <> wrote:
>> On Feb 9, 2009, at 11:23 AM, Paul Davis wrote:
>>>>> Assuming the replication processes doesn't interleave documents  
>>>>> from
>>>>> different MVCC commits,
>>>> I believe that's correct.
>>> I think it's only correct if you don't edit the doc after the
>>> _bulk_docs call. Making two calls to _bulk_docs and then editing a
>>> document from the first transaction would make things interleave I
>>> think.
>> It sounds like we're on the same page, Paul.  If you define a  
>> commit as a
>> list of id/rev pairs there's no interleaving.  Call the doc that  
>> was edited
>> twice A/"foo" and A/"bar".  A/"foo" is part of the first  
>> _bulk_docs, and it
>> disappears from the replication stream once A/"bar" lands.
>> Adam
> In that case I'd agree, but as I understand it the data associated
> with A/"foo" never gets replicated, only the _id/rev pair to inform
> the other side that the state existed. And further it's only
> replicated when the process gets to A/"bar".
> I'm a bit hazy on the details, but my understanding is that it'd be
> impossible to have knowledge of A/"foo" prior to reaching A/"bar" in
> the update_seq. As in, knowledge of the update_seq for A/"foo" is
> removed (Other than it happened before A/"bar" that is).
> HTH,
> Paul Davis

Yes, good point.  The A/"foo" metadata does get added to the revision  
history for A on the target, but not till the replicator reaches  
A/"bar".  I suppose you could call that interleaving.


View raw message