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
