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