couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: svn commit: r815984 - in /couchdb/trunk: share/www/script/test/view_include_docs.js src/couchdb/couch_httpd_db.erl src/couchdb/couch_httpd_view.erl
Date Thu, 17 Sep 2009 04:32:34 GMT
On Wed, Sep 16, 2009 at 6:42 PM, Chris Anderson <jchris@apache.org> wrote:
> On Wed, Sep 16, 2009 at 3:04 PM,  <jchris@apache.org> wrote:
>> Author: jchris
>> Date: Wed Sep 16 22:04:18 2009
>> New Revision: 815984
>>
>> URL: http://svn.apache.org/viewvc?rev=815984&view=rev
>> Log:
>> include_docs now take an _id (as well as a _rev) in the emitted value, to load docs
other than the one doing the emitting. This means you can have one doc list a set of other
docs to load in a single query. Enjoy!
>>
>
> In Governator voice: "It's not a JOIN."
>

Good to see you're acclimating to SF. :)

> But you can use it if you have a doc like:
>
> {"_id":"my-outline",
> "other_docs":["docid,"other-docid"]
> }
>
> and then a view like
>
> function(doc) {
> for (var i=0; i < doc.other_docs.length; i++) {
>  emit([doc._id, i], {"_id" : doc.other_docs[i]}
> };
> }
>
> and then you will have an ordered list of the other docs available in
> a view query (with include_docs) You can also specify the other docs
> _rev if you want -- if it's not available it comes up as null in the
> feed.
>
> Of course, the usual include_docs performance caveats apply, but this
> time we get a feature out of it!
>
> Chris
>
> --
> Chris Anderson
> http://jchrisa.net
> http://couch.io
>

I'm definitely keen on this idea, but a thought:

The current patch is basically a limited version of Riak's Jaywalker.
Once i saw that I immediately started contemplating how to add a
similar feature to couch. I got hung up on the fact that Riak uses
more structure in their docs to provide a links field. When Chris
today mentioned emitting a value that had an _id variable I was
hooked.

So while the basic premise is quite awesome, I've got a slightly more
generic idea, instead of using emit(key, {_id: foo}) why not us {_key:
foo} and it looks up rows in the view. Its subtle, but the extension
is that it allows for further chaining. And then to get the actual doc
we recognize ?include_docs=true and then any returned row gets that
doc.

The one downfall of this is that it falls victim to the same
controversy over POST for multi-key fetch as its an unbounded length
value but URLs would be limiting. Right now I'd vote for adding URL
multi-key and then adding the _key follow as either a URL endpoint or
a POST body or url parameter.

Still, way cool feature.

Paul

Mime
View raw message