couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <>
Subject Re: View changes API
Date Wed, 13 Aug 2014 09:46:31 GMT
On Wed, Aug 13, 2014 at 11:27 AM, <> wrote:

> 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.

Thanks :) Where can I see the code?

> First of all, the view changes in rcouch endpoint looks like:
> /:db/_changes?filter=_view&view=:design/:view
> I'd suggest changing this to be something like:
> /:db/_design/:design/_view_changes/:view
> or possibly
> /:db/_design/:design/_view/:view/_changes

The main reason the view changes is above is to replace the current
inefficient "_view" filter. Qhat would you do for ths one? Simply removing
it? How would you handle the replication using this filter?

> 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.

without the index, what would be the query on the views changes? Would it
only handle querying the changes by key? (ie not in a range?)

- benoit

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