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
