Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of paul.joseph.davis@gmail.com
 designates 209.85.217.162 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=s5FuASVC4o4zxMx0fzKkk+fN51k+vLUw/Gb1MhvcF6yYmflN7JA4nHNCXEzG9dIKqt
         PHAesO4ZkbdNoCGGocVi2/Xpz2RdmPpgaiz1FBSImSMqbhqUYx/LL8TdMYQ6q6o5o2tA
         /gL6QhY+tovbAyF4Vgcjdalp9A3intPEVvrFk=
MIME-Version: 1.0
In-Reply-To: <B0CC0CCF-977E-4FBB-AC26-19574178FC77@gmail.com>
References: <B0CC0CCF-977E-4FBB-AC26-19574178FC77@gmail.com>
Date: Thu, 9 Apr 2009 19:20:42 -0400
Message-ID: <e2111bbb0904091620w40010ec1w311a3afb97d43bc9@mail.gmail.com>
Subject: Re: View Intersections
From: Paul Davis <paul.joseph.davis@gmail.com>
To: dev@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On Thu, Apr 9, 2009 at 5:45 PM, Sho Fukamachi <sho.fukamachi@gmail.com> wrote:
> Dear ML,
>
> Sorry about the new Message-ID.
>
> I am wonder if Paul Davis's planned work on view intersections went anywhere
> / is there anything to play with / turned out to be a bad idea?
>
> Reference:
> http://mail-archives.apache.org/mod_mbox/couchdb-dev/200902.mbox/%3Ce2111bbb0902101559x251b9ae7j40bc5463c11d9c3f@mail.gmail.com%3E
>
> I thought that feature was a pretty big deal - just wondering if there's any
> new information.
>
> thanks!
>
> Sho
>
>

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