incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Scholl ...@diskware.net>
Subject Re: couch_gen_btree: pluggable storage / tree engines
Date Sun, 01 Feb 2009 13:52:48 GMT
Hello Robert,


Robert Dionne wrote:
> Martin,
> 
>   I'm very keen on relationships between documents. Coming from the
> description logic community, I'd like to allow users to declare certain
> fields that relate documents and then compute transitive closures over
> dags whose nodes are documents and whose arcs the fields of interest.
> This goes against the grain of  couchdb as collections of unrelated
> documents, I know, but it's what I want to do as couchdb's schema-less
> design offers many advantages over relational databases. Relational
> databases aren't that great for storing graphs either.
I like the idea (reminds me of an RDF DB btw), especially when used
together with views.

> 
>   I don't need to run full classification algorithms in the document
> store, but would like to just maintain relationships (user-defined) and
> transitive closures of them. Inferencing would perhaps be better done
> externally similar to the hypercouch work. So this would best be served
> by pluggable indexing and maybe pluggable storage, though I think I
> could live without the latter for now.
With Antony's latest hints (thank you Antony!) in mind, I think I will
implement first sketches in an external way first. FTI is implemented in
the same way afair.

> 
>   So I'm very excited about your ideas. I too have been reviewing the
> code with this in mind and I would agree with others that it's perhaps a
> post 1.0 task. From the little time I've spent chasing down a couple of
> bugs I've seen there are a few subtle aspects to it. I've also noticed
> that the style of design in this community is more bottoms up, which is
> how it should be when building something new, so prototypes are perhaps
> better for fleshing out ideas. Anyway I'm very happy to help an d
> collaborate on this as I can.
Great! I will just publish my results on github. I hope, others will
join then.

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?


Martin

Mime
View raw message