couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Barry Wark <>
Subject Re: View Filtering (was Re: The 1.0 Thread)
Date Mon, 22 Jun 2009 23:27:01 GMT
On Fri, Jun 19, 2009 at 1:53 PM, Chris Anderson<> wrote:
> On Fri, Jun 19, 2009 at 1:42 PM, Barry Wark<> wrote:
>> If I may, I would like to put a +1 on ability to intersect (or union)
>> multiple view results. This is the feature that's preventing
>> whole-hearted adoption of CouchDB for several applications at my
>> company. Lucene is close to a solution, but we really need proper
>> numeric comparisons, not just text comparisons. I don't think we can
>> commit any resources to making a patch happen on this front until
>> Jan/Feb. 2010. At that time, we would be willing to help make  this
>> happen as we're quite excited about CouchDB but are being held up by
>> the lack of boolean view combinations (the data sets in question are
>> too large to handle the logic client-side).
> It should be possible to accomplish a crude version of this with the
> current list API. The idea is that you'd write a view that sorts by
> your most fine-grained attribute.
> Say you want to query based on city AND cuisine-type, you'd have a
> view that sorts by city, and then run that through a list function
> which only outputs view rows where the cuisine type matches a query
> parameter. Of course all the rows for the city in question are
> processed on the server, but only those for Thai food in Portland are
> actually returned to the client (as the original JSON if you like).
> The approaches for making this less crude are: one, to do basically
> the same thing in Erlang (lotsa code, less flexible, brittle when
> other parts of the view internal change, but slightly less overhead
> than running it in a list function.) Or two: to do some kind of
> complicated bit field indexing stuff like relational databases do for
> this sort of thing. Of course we'd be happy with patches along these
> lines, but they are distant from the current API and code base.
> Another simple option would be to use something like SQLite as an
> external indexer.
> Does this help?

Yes, this does help me start thinking about options. Like I said, it's
going to be a few months until I/we can dedicate any resources to the
effort. In the mean time, I'll take these comments to heart.


> Chris
> --
> Chris Anderson

View raw message