Thank you - that answers the question perfectly. Makes my life more complex, but more interesting.
Nick On 7 February 2012 16:11, Robert Newson <rnew...@apache.org> wrote: > The replicator replicates in parallel, so even if this property held, > replication will violate it. There is no transactional boundary > greater than a single document update. > > B. > > On 7 February 2012 16:03, Nick North <nort...@gmail.com> wrote: > > I have a question about the order in which documents are committed to the > > database, which I hope a knowledgeable dev can help me out with. > > > > The question is (I think): if I create documents, using CouchDb-assigned > > document ids, will they appear in the _changes feed in the order that the > > ids were assigned? For example, if the id generation algorithm > successively > > supplies ids aa, bb, cc, will the changes feed contain aa, bb, cc in that > > order, or could a document with a later id "overtake" an earlier one in > the > > process of being committed to the database to yield, say, aa, cc, bb? A > > secondary question is: if the order is preserved, can that be relied on > in > > future CouchDb versions, or is it coincidental and may change one day? > > > > A bit of background might help, and may possibly suggest that I'm not > > asking the right question. I have a set of mutually replicating databases > > which have a CouchDb id generation algorithm that produces monotonic > > increasing globally unique document ids (details > > here<https://issues.apache.org/jira/browse/COUCHDB-1373>). > > I'd like to be certain that, if document id xx has been replicated from > one > > database to another, then all documents that are replicated later have > > higher ids than xx. It struck me that this might not be the case if > > multiple simultaneous document creations are processed concurrently and > get > > their document ids assigned early in the process - then a small document > > with a later id might be processed more quickly than a large one with an > > earlier id and get into the database first. > > > > Any insights would be very much appreciated. Many thanks, > > > > Nick >
