Ah, good point about the replication filtering. That's tricky. I'll think about that tomorrow.
On Wed, Aug 13, 2014 at 5:01 PM, [email protected] < [email protected]> wrote: > 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 <[email protected]> > wrote: > >> On Wed, Aug 13, 2014 at 11:27 AM, [email protected] < >> [email protected]> 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 >> > >
