Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of antony.blakey@gmail.com
 designates 209.85.200.171 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:from:to:in-reply-to:content-type
         :content-transfer-encoding:mime-version:subject:date:references
         :x-mailer;
        b=f0mu+AllJP47HIHXDY3iWe2yKU44uAe7pBESz3pxX+JSIRkU27sPPp+cHqK+IXhdvH
         mvQqRya/OyXjmw2pXRhw8ao7ycoFX6/dl/+8mvbSaUzF1j9T4d9RQWXcICm3Z1TI6Z14
         TEskNfXiH2s+/wL5fRnKf3HjT1Y7vIfuGac8g=
Message-Id: <2F32C6DA-D91B-4CFB-8561-9E404D6EAA3F@gmail.com>
From: Antony Blakey <antony.blakey@gmail.com>
To: dev@couchdb.apache.org
In-Reply-To: <4985A930.4050802@diskware.net>
Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: couch_gen_btree: pluggable storage / tree engines
Date: Mon, 2 Feb 2009 09:21:57 +1030
References: <498464EC.1070209@diskware.net>
	 <e2111bbb0901311956x5040956elf76c3fe17e7526bd@mail.gmail.com>
 <e282921e0901312030o30f6abawb4e6905fcb048bc4@mail.gmail.com>
 <49859AB5.7080404@diskware.net>
 <5FCD4937-E8BD-4024-9E46-A24061F4D322@dionne-associates.com>
 <4985A930.4050802@diskware.net>


On 02/02/2009, at 12:22 AM, Martin Scholl wrote:

> What worries me most, is that I am still unsure in how to differ =20
> between
> design docs and indexing schemes, and when to use which =20
> infrastructure.
> Applied to the doc-relationship example you gave: how should
> "intermediate reults" of the dag processing be treated? As documents?
> Should they be put into view functions? Should views be able to hint,
> which indexing scheme is to be used? Depending on the index type,
> indexing and doc / view-processing can become inherently coupled and
> complex. Is this still CouchDB then?

No sure if this is exactly what you're talking about, but the way I =20
was thinking (which I picked up from GeoCouch) was to have design docs =20=

that define no couch view, that allow you to configure the external =20
e.g. in my case, which was for returning the TC of  user/role/=20
permissions graphs, that might look like this:

{
   "_id": ...,
   "_rev": ...,

   transitive_closure_generator: {
     "User": { "from": "_id", "to": "[roles]" },
     "Role": { "from": "_id", "to": "[permissions]" },
   }
}

Then, in my external I process such docs in my update-loop to generate =20=

the configuration of the external i.e. I monitor changes to design =20
docs with a 'transitive_closure_generator' element, obviously caching =20=

and persisting that configuration. You also need to catch design docs =20=

updates that remove that element, and the deletion of monitored docs =20
as well.

Because I use CouchRest, I can use the 'couchrest-type' key that it =20
inserts to identify which document's fields I need to process e.g. =20
'User'/'Role'.

As an aside, it might be nice if you could use that doc to define the =20=

endpoint for your externals, so you could completely simulate a built-=20=

in view. Putting external configuration into design docs isn't good =20
idea but maybe it could be indirect e.g.

{
   "_id": 'my_design',
   "_rev": ...,

   transitive_closure_generator: { ... }
   externals: {
     view_name: 'tc',
     external: <the id of the external mapping in the .ini>
   }
}

which would then allow you to access your external via '_view/=20
my_design/tc'. External views mapped like this would need to adhere to =20=

the view contract e.g. params etc.

Antony Blakey
--------------------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

Always have a vision. Why spend your life making other people=92s =
dreams?
  -- Orson Welles (1915-1985)