On Fri, Jun 19, 2009 at 1:42 PM, Barry Wark<[email protected]> 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? Chris -- Chris Anderson http://jchrisa.net http://couch.io
