couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "" <>
Subject View changes API
Date Wed, 13 Aug 2014 09:27:00 GMT
Hey all,

I've been working on merging the view changes functionality from rcouch
into CouchDB. I've made a few (hopefully) uncontroversial tweaks, but I'd
like to build some consensus on what the API should look like before I go
much further.

First of all, the view changes in rcouch endpoint looks like:


I'd suggest changing this to be something like:

or possibly

Secondly, the merge adds a couple optional flags to the design doc (both
disabled by default):

1) A flag to enable most view changes functionality
2) A flag to enable efficient querying of the view changes feed over a
range of keys. (eg. if a view emits keys in the form of [year, month, day],
you could query for all the changes which are between [2014, 3, 10] and
[2014, 3, 20])

In rcouch, the flag for #1 is called "seq_indexed". That name may be a bit
opaque to a user. Maybe something like "enable_changes"?

#2 doesn't exist in rcouch (ie. enabling the "seq_indexed" flag in rcouch
creates an extra index solely for view changes queries over a range of
keys). I've talked with some people about making the key+seq index
independent from the base view changes index. If they were independently
optional, you'd be able to use the view changes functionality without
creating an unused key+seq index (or vice versa). I've found that people
generally think that it's a good idea, but if anyone disagrees, feel free
to bring it up. I've already implemented the necessary changes for this
behavior, but I need a good flag name. Maybe "enable_keyed_changes"?

Otherwise, I think it'd be good to reuse the query string/POST body options
from the normal _changes endpoint.



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message