couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sho Fukamachi <>
Subject Re: View Intersections
Date Fri, 10 Apr 2009 09:46:43 GMT
Hi Paul,

thanks for the reply - not trying to point out anything! : ) I did  
think the original thread made the proposed functionality sound  
suspiciously easy to implement! Well, always like this.

I'm still not good enough at Erlang to offer any implementation  
comments worth reading, so I'll refrain from that.

However, if it is doable, I think it could be a very important  
feature. To choose just one of many use cases, numerous view examples  
in the wiki and elsewhere revolve around the scenario of document tags  
- the obvious followup question to those examples is "well, how do I  
find a document with all of (n) tags?". Somehow gaining that  
functionality would be a real coup, IMO, it would instantly deliver a  
kind of n-level arbitrary-tag SELECT and the implications for where  
and how you could use CouchDB would be huge. Especially since doing  
that kind of thing with SQL is no walk in the park.

So anyway I just sort of wanted to say, +1 to view intersections, if  
they're at all possible!

thanks again,


On 10/04/2009, at 9:20 AM, Paul Davis wrote:

> Sho,
> Thanks for pointing out my inadequacies. XD
> I'm still working through how to tackle the different kinks that
> turned out in various ways to be bigger than I imagined.
> The biggest one so far is that the way reductions are implemented I
> can't persist a value index which breaks intersections for anything
> that has a reduce step. I tend towards not jumping in and doing the
> half-assed "we don't support reduce" implementation because, well, its
> half-assed. And the severe lack of possible functionality would be a
> constant reminder that I had failed as a programmer.
> The second thing I'm also not quite sure about is the sort order when
> joining > 2 indexes. It may turn out that doing such a thing is
> severely limiting in terms of a dynamic query because it'd require all
> join points to have the same key possibly. It'd definitely require
> that the entire thing were sorted in the same direction but that
> shouldn't be as big of a deal.
> There's also the possible headache of cross product output. For the
> instance when say, two views emit ("ohai!", null) 1M times, then any
> sort of join is going to end up with 1M^2 rows. Granted it'd be
> streamable :D
> Anyway, those are the hurdles I've got and I'm still doing work in my
> spare time to try and tackle different aspects.
> HTH,
> Paul Davis

View raw message