On Feb 9, 2009, at 12:35 PM, Paul Davis wrote:
On Mon, Feb 9, 2009 at 11:46 AM, Adam Kocoloski
<[email protected]> 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.
Adam
