couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: couchdb transactions changes
Date Mon, 09 Feb 2009 17:35:35 GMT
On Mon, Feb 9, 2009 at 11:46 AM, Adam Kocoloski
<adam.kocoloski@gmail.com> 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

Mime
View raw message