Heya Nate, I think you’ve mostly got it in terms of what a local_seq is and how to use it.
In terms of CouchDB there is no reliable way to make use of them that would have any other semantics than the regular changes feed already has (and I consider n=1&q=1 dbs a special case here rather than something you should rely on). We have a larger discussion[1] going on on dev@ that might shine new light on this, so it might be worth diving into that :) Best Jan — [1]: https://lists.apache.org/thread.html/04e7889354c077a6beb91fd1292b6d38b7a3f2c6a5dc7d20f5b87c44@%3Cdev.couchdb.apache.org%3E > On 23. Jan 2019, at 23:23, Nathan Vander Wilt <nate-li...@calftrail.com> > wrote: > > 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 <nate-li...@calftrail.com> > 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 >> -- Professional Support for Apache CouchDB: https://neighbourhood.ie/couchdb-support/
