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,
Sho
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
