Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of benjamin.bastian@gmail.com
 designates 74.125.82.43 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAJNb-9pjkwfWV22z7hRAsHjfJUuP9gb7r6KsQ1niH=G3i_Rr9A@mail.gmail.com>
References: 
 <CAM3vACW7Kxdg9F-1MZya8NA-fHMmjSQun-d6WR1h9M3=1nvqjA@mail.gmail.com>
	<CAJNb-9pjkwfWV22z7hRAsHjfJUuP9gb7r6KsQ1niH=G3i_Rr9A@mail.gmail.com>
Date: Wed, 13 Aug 2014 17:01:42 +0700
Message-ID: 
 <CAM3vACW-NLQWgHjxduMUtn+3dwnWuHbKdujQpS1j6R3sznNYSw@mail.gmail.com>
Subject: Re: View changes API
From: "benjamin.bastian@gmail.com" <benjamin.bastian@gmail.com>
To: dev@couchdb.apache.org
Content-Type: multipart/alternative; boundary=001a11c347e0f9f9ff05007fdfe2

--001a11c347e0f9f9ff05007fdfe2
Content-Type: text/plain; charset=UTF-8

The work-in-progress code is here:
https://github.com/sagelywizard/couchdb-couch
https://github.com/sagelywizard/couchdb-couch-mrview
"working" branch on both repos.

For the _view filter, I'd suggest either 1) removing it or 2) leaving it
as-is.

For doing a view changes query for a range of keys when the key-seq index
wasn't enabled, I'd suggest returning an error. "view changes by key not
enabled" or some such.


On Wed, Aug 13, 2014 at 4:46 PM, Benoit Chesneau <bchesneau@gmail.com>
wrote:

> On Wed, Aug 13, 2014 at 11:27 AM, benjamin.bastian@gmail.com <
> benjamin.bastian@gmail.com> 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
>

--001a11c347e0f9f9ff05007fdfe2--