For filtered replication, I think it'd be good to keep the rcouch
filter=_view optimization when the appropriate flag is enabled. If the
flags aren't enabled, fall back on the old, inefficient style of filtering.
For someone querying view changes feed, I imagine they'd be interested in
which keys and values are changing rather than just which docs in the view
are changing. So, for a new "view changes" endpoint, I think it'd be good
to include the key (as well as the doc ID) in the response body. So, rows
would in a response would look something like:
{"seq": <seq>, "id", <doc id>, "key": <emitted key>, "changes": <changes>}
Also, it might be good to add an include_values option to do
include_docs-style lookups for the emitted values which correspond to the
emitted keys.
Thoughts?
On Thu, Aug 14, 2014 at 1:00 AM, [email protected] <
[email protected]> wrote:
> 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
>>>
>>
>>
>
