couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Prater <>
Subject Re: Filtering of view results
Date Mon, 13 Sep 2010 21:00:21 GMT
You don't need to create different views, I don't think, you just need  
to emit all the permutations of the view parameters.

So, you know, if you had parameters D, B, P, you'd have to emit 6  
times.  (if that was Date, Branch, Platform)


That would let you do range queries based on what was being filtered  
on, so for filtering by date, branch, and platform
you would choose query one.

I think you'd need to sort each entry so they show up together.

Or, you could use couchdb-lucene.  I'm pretty sure it does something  
very similar with a custom indexer.


On Sep 13, 2010, at 3:46 PM, Henrik Skupin wrote:

> On Mon, Sep 13, 2010 at 12:14 AM, Dirkjan Ochtman  
> <>wrote:
>>> I hope that is somehow possible.
>> It's not, you need two different views.
> This worries me a lot. Because I will never be able to filter on  
> more than
> one key at the same time. I don't want to create a dozen of  
> different views
> to handle this specific requirement.
> What I really miss is a filter parameter which will be executed when
> accessing a view and which will accept/deny b-tree entries depending  
> on the
> filter criteria. Here some examples:
> viewName                                               No filtering
> viewName?filter=[{}, {}, {}]                       No filtering
> viewName?filter=["09/13/10", {}, {}]         Only return rows from  
> Sep 13th
> 2010
> viewName?filter=[{}, "4.0", {}]                  Only return rows  
> for the
> 4.0 application branch
> viewName?filter=[{}, {}, "Mac"]                Only return rows on Mac
> viewName?filter=[{}, "4.0", "Mac"]           Only return rows for  
> the 4.0
> application branch on Mac
> This thread is probably similar to the "missing join" thread we have  
> right
> now. But instead of having multiple views a single view should be  
> totally
> enough. All the information we have to query on should be part of  
> the key,
> so filtering on specific entries should be possible. Or is there a
> limitation on the b-tree side?
> For us it will be a hard requirement. If it can't be solved easily  
> with
> CouchDB, we probably have to switch to another backend storage. But I
> wouldn't like to do that because Couchdb is impressive and I want to  
> support
> it.
> -- 
> Henrik Skupin
> QA Engineer
> Mozilla Corporation

View raw message