couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antony Blakey <antony.bla...@gmail.com>
Subject Re: couch_gen_btree: pluggable storage / tree engines
Date Sun, 01 Feb 2009 22:51:57 GMT

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  
> between
> design docs and indexing schemes, and when to use which  
> 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  
was thinking (which I picked up from GeoCouch) was to have design docs  
that define no couch view, that allow you to configure the external  
e.g. in my case, which was for returning the TC of  user/role/ 
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  
the configuration of the external i.e. I monitor changes to design  
docs with a 'transitive_closure_generator' element, obviously caching  
and persisting that configuration. You also need to catch design docs  
updates that remove that element, and the deletion of monitored docs  
as well.

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

As an aside, it might be nice if you could use that doc to define the  
endpoint for your externals, so you could completely simulate a built- 
in view. Putting external configuration into design docs isn't good  
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/ 
my_design/tc'. External views mapped like this would need to adhere to  
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’s dreams?
  -- Orson Welles (1915-1985)


Mime
View raw message