couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <>
Subject Re: Order of document ids vs order of _changes ids
Date Tue, 07 Feb 2012 16:11:16 GMT
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.


On 7 February 2012 16:03, Nick North <> 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<>).
> 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

View raw message