On Mon, Feb 9, 2009 at 11:16 AM, Adam Kocoloski <adam.kocolo...@gmail.com> wrote: > On Feb 9, 2009, at 7:22 AM, Antony Blakey wrote: > >> On 09/02/2009, at 10:09 PM, Antony Blakey wrote: >> >>> On 09/02/2009, at 9:33 PM, Antony Blakey wrote: >>> >>>> 2. Record commit boundaries, possibly by recording a transaction-seq >>>> with each document rev. I'm aware that this *is* about reifying underlying >>>> transactions, but at least the reification is implicit. >>> >>> Actually, that could form the first part of the new compound revs >> >> 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. >> I'm now thinking that all that is needed is for each rev to include a MVCC >> commit # (== transaction id); commit #'s would be allocated at the start of >> an MVCC transaction (because they would be needed within the commit), and >> hence would not be a strict ordering. You can then detect MVCC commit >> boundaries by detecting when the commit # changes. No change required to the >> source replicator, and target replication could take advantage of that at >> some future stage. >> >> This would allow for consistent replication of transactions, if they were >> provided, with replication possible at a MVCC commit granularity i.e. no >> problem with huge replications. > > But we still have the problem that ... > > On Feb 9, 2009, at 12:58 AM, Antony Blakey wrote: > >> The document revision created in the _bulk_docs will still show up in the >> replication stream - it does now doesn't it? > > > No, not necessarily. Each doc shows up exactly once in the replication > stream -- at the update_sequence of its latest revision. Best, > > Adam >
