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 <[email protected]> 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
