On Tue, Mar 17, 2009 at 10:49:29PM -0700, Daniel Friesen wrote:
> Ok, I started a document here:
> http://wiki.apache.org/couchdb/Forward_document_references
>
> There is a little more of the document to write. And I don't get how to  
> format the code so it isn't messed up.

Use triple-braces:

{{{
stuff in here
is unformatted
}}}

As for the proposal itself, my initial thought was that instead of

  [
    {"_document","foo"},
    {"_document","bar"}
  ]

you could have

  {"friends":["foo","bar"]}

and then you could query ...?recursive=friends&maxdepth=6

As well as being more compact, it also allows for different types of graph
edge to exist concurrently (friends, employees, pets, ...)

However in practice I tend to use backward edges ("belongs to") rather than
forward edges ("has many"), and so for me it would be much more useful to be
able to traverse the graph that way. This can be done just as efficiently as
long as there's a view which emits the [src, dest] pairs.

And therefore, I think a better solution for this recursive fetching is for
it to be done based on views rather than documents. This completely
eliminates the need to have a special field within the document, e.g. the
"_document" field that you propose, since the map part of a view can extract
whichever field(s) are of interest.

So, suppose in your example you had a map view which emitted

  key           value
  ---           -----
  src_id        dst_id
  src_id        dst_id
  src_id        dst_id
  ...

then when you fetch srcdoc, you could find all the next-level related
doc_ids from the view in one hit, then do a multi-doc fetch to retrieve the
actual documents, and repeat to maxdepth.

This is something which can be done client-side without too much work using
multi-doc fetch, using up to 2 x 'maxdepth' separate calls (*). It would
certainly be more efficient to do this server-side, and there is also the
question of consistency if the database is changing. A server-side operation
could perform multiple queries on the same point-in-time snapshot of the
view. This, for me, is the main argument for having the functionality
server-side.

I'm not sure where such functionality would best be added - as an option to
the view server itself, or as an _external module.

Regards,

Brian.

(*) Which in your 'friends' example, in the case where each person has only
one friend, is not very efficient. That is, it works OK for wide trees but
not for deep and narrow trees.