I'm also wondering if it would be reasonable to file a feature request for
a new _changes option, `local_seq=true` which would behave like the same
option on a document request (perhaps only having an affect when
include_docs=true too).

Previously this was not necessary since the sequence numbers in the changes
feed *were* the local_seq. But now the changes feed provides only the
global sequence. For consistency with view generation and document fetches
it would be nice to have this available to change watchers as well.

thanks,
-natevw

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
>

Reply via email to