couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick North <nort...@gmail.com>
Subject Re: Order of document ids vs order of _changes ids
Date Tue, 07 Feb 2012 16:47:47 GMT
Thank you - that answers the question perfectly. Makes my life more
complex, but more interesting.

Nick

On 7 February 2012 16:11, Robert Newson <rnewson@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 <north.n@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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message