I can see filters applied to views and replication, since lists are essentially a filter with formatting. I understood the proposal being the other way around using view (or map) for replication filtering.
Chained filtering would be nice - albeit, I'm not sure how efficient it would
be since the worst possible case you'd be O = n*m where n is the number of
filters, m is the number of docs.
Jim Klo
Senior Software Engineer
Center for Software Engineering
SRI International
On Jan 29, 2012, at 2:07 PM, Alexander Shorin wrote:
> IMHO, that's nice idea to apply filter or set of filters to view result.
>
> Some examples:
> Your database contains set of articles. Your view looks like:
> function(doc){
> if (doc.type == 'article')
> emit(doc.title, doc)
> }
> Fine. Now you'd like to get articles that have been created by user
> group managers? No problem, just create new view with user group
> check. Wanted to emit only those who had any comments? Get another
> one. And so on, and so on. Instead of this, you may just apply set of
> filters to view result and customize output it on fly! Like this:
> /_design/articles/_view/by_title?filters=[only_managers,has_comments,has_positive_rating]
> If you're ready to pay some performance hit for this, you've got 4
> views by cost(disk-space) of single one.
>
> Now let's take a look a little closer...
> Common filter function takes two arguments: doc to filter and request
> information:
> function(doc, req){
> ...
> }
> and should return boolean to mark has doc passed or not.
>
> View internals could surely say what document could be processed in
> map mode. If you apply reduce function this information is lost for
> oblivious reasons. So this idea could live for only map views if we
> operating with documents. This means, that this filters should be
> applied after map function execution and before reduce one. Since the
> fact that reduced view result calculated for each request and doesn't
> stored in view index file(am I wrong?) this feature is quite possible
> to be real, theoretically(:
>
> P.S. There is nothing about replications due to views are already
> could be used as filters. Creating mix of views/filters I've found a
> little crazy.
>
> --
> ,,,^..^,,,
>
>
>
> On Mon, Jan 30, 2012 at 1:39 AM, Jim Klo <[email protected]> wrote:
>> I could see it as a bad idea in that views usually have a different
>> collation from the changes feed. Views also can emit more than 1 key/value
>> per doc, which I'm not sure how that works with filters. I suppose it's
>> possible, but you'd still have to follow the changes sequence, but when
>> applying the map function, you replicate only the id emitted once.
>>
>> - Jim
>>
>> Sent from my iPad
>>
>> On Jan 29, 2012, at 11:35 AM, Dave Cottlehuber <[email protected]> wrote:
>>
>>> On 29 January 2012 18:13, Benoit Chesneau <[email protected]> wrote:
>>>> On Sun, Jan 29, 2012 at 8:54 AM, Daniel Gonzalez <[email protected]>
>>>> wrote:
>>>>
>>>>>
>>>>> - Am I doing something wrong in the curl calls?
>>>>> - Is it at all possible to use views together with filters, or are
>>>>> filters limited to the _changes feed? I have seen no examples of
>>>>> filters except related to _changes
>>>>>
>>>>
>>>>
>>>> filters are only expected for _changes.
>>>>
>>>> - benoît
>>>
>>> Although it might be interesting to factor out filters (in changes and
>>> replication) and to manage them the same way as views, including being
>>> able to use views as replication targets, and avoid needing to
>>> reprocess the filter each time.
>>>
>>> I'm sure that when I think about this after my wine, I'll come up with
>>> some good reasons why thats not a great idea.
>>>
>>> A+
>>> Dave
smime.p7s
Description: S/MIME cryptographic signature
