couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "benjamin.bastian@gmail.com" <benjamin.bast...@gmail.com>
Subject Re: View changes API
Date Wed, 13 Aug 2014 18:00:37 GMT
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, benjamin.bastian@gmail.com <
benjamin.bastian@gmail.com> 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 <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
>>
>
>

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