Hi Adam, Thanks for your answer. For me the important part is the “at least once” processing, so I’m comforted as far as that’s concerned!
Now out of curiosity, let me verify if I understand this correctly: - when I get the _changes of a cluster, it’s constructed ad hoc from the _changes of its shards, so in 2 consecutive requests, the ordering might differ? - if I pass a ‘since’ parameter to the cluster _changes, the cluster derives ‘since’ parameters for all of its shard from it? - the _changes of a shard are taken from any of its replica’s, so in 2 consecutive requests, also these might differ slightly? - it can be derived from the ‘since’ parameter of a shard from which replica it comes? Do you know any documentation/article/blog on how this works in CouchDB (clustering in general, and the changes feed more specifically), maybe an article not specific to CouchDB but describing the strategy use by it? Thanks in advance, Roald > On 31 Mar 2015, at 19:47, Adam Kocoloski <kocol...@apache.org> wrote: > > A few scenarios here: > > * Any v2.x database with no replicas (N=1) and only one shard (Q=1) will > recover the v1.x behavior exactly. > * Any database with replicas but only one shard will have roughly ordered > events. If a replica dies and gets repopulated from its peers you may see > some reordering. > * Each shard of a database contributes to the _changes feed as fast as it can > without any regard to total ordering. > > The v2.x _changes feed still guarantees "at least once" processing; i.e., you > can still store the last processed change and continue from there at any > moment. > > If you need sharding _and_ complete ordering of events then you should > probably store a timestamp with each document, build a view keyed on > timestamp, and have your async process consume that. > > Adam > >> On Mar 30, 2015, at 7:07 AM, Roald de Vries <webthusi...@gmail.com> wrote: >> >> Hi all, >> >> I’m considering how I can make my application forward compatible with v2.0, >> and I see a potential problem with that (for my use case): >> >> I have a front-end that generates events, which I store in CouchDB. An >> asynchronous back-end process listens to a feed of these events, and writes >> an aggregate back to the db. I can’t use a view for this, because the >> aggregate also depends on documents referenced from the event documents. >> >> For this to work, I need to be sure to process every event, and in the >> correct order. I v1.X, I can simply store the last processed change, and >> continue from there at any moment. Would this still work in v2.0? As I >> understand now, the order of the changes in v2.0 is no longer ordered. Is >> there a way to still get a consistently ordered feed from? >> >> Thanks in advance, Roald >
