If anyone else ends up finding this, I posted roughly the same question on Stack Overflow and also added a tentative answer with my own discoveries: https://stackoverflow.com/questions/54336456/what-is-the-behavior-of-local-seq-under-couchdb-2-x
The summary is that _local_seq is *per-shard* and so of somewhat dubious value in a "changes view" context anymore unless q=1 (which in my case is totally fine). As far as its relationship to the _changes feed, there's some good discussion of the internals at http://mail-archives.apache.org/mod_mbox/couchdb-user/201706.mbox/%3C70C89252-BA26-43F5-BD0B-62A6814EF904%40apache.org%3E hth, -nvw On Thu, Jan 17, 2019 at 4:26 PM Nathan Vander Wilt <[email protected]> wrote: > I'm updating some code and wondering how I should understand local_seq in > the CouchDB 2.x era: > > > Is the doc._local_seq field still guaranteed to be incremental and unique > for documents within a database stored only on a single-node? Or does it > now apply only at the shard level? > > > If I do ever migrate to multiple nodes, what should I expect regarding > local_seq in those circumstances? > > > Finally, is there any relationship between the doc._local_seq and the > db.update_seq/change.seq values *if* I assume a single-node CouchDB 2.x > instance only? If not, is there any [at least theoretical] way that a view > could get access to a "global seq"-compatible token in addition to the > local_seq? (I took a gander at the handle_message/pack_seqs code > in fabric_view_changes.erl but couldn't make much sense of it without > understanding more of its context.) > > > > > Background: > > > I am trying to migrate a "scoped changes" propagation implementation from > CouchDB 1.x to CouchDB 2.x. The goal of the implementation is so that a > client can track changes within a given scope (e.g. a certain group within > a certain user's data). > > > In my original (CouchDB 1.x) implementation I simply added a > `data_by_scope_and_seq` view that emits every relevant document under a key > like `[user, topic, sequence]`, leveraging `{local_seq:true}` option on the > design document. Then I could get a list of all changes by querying with > `startkey=[user,topic]&endkey=[user,topic,{}]` or recent changes by > extending the startkey. > > > My middleware built on top of both this and the database-level _changes > feed to provide long-polling to clients within each scoped feed. This > logic, as currently implemented, broke when I updated to CouchDB 2.x. It > assumed each document's local_seq corresponded with the database-level > seq/update_seq values, but the latter sequence values are now a separate > and opaque token. > > > thanks, > > -natevw >
