couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curt Arnold <curt.ar...@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 02:26:31 GMT

On Sep 16, 2009, at 5:42 PM, Chris Anderson 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."
>
> 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
>


I'm thinking that this may be sufficient to address the use case  
described in http://wiki.apache.org/couchdb/ 
Forward_document_references.  I was uneasy about that proposal since  
it strongly favored using one document per entity when that model may  
not be the appropriate partitioning scheme, but I never bothered  
putting my thoughts down since it looked like it wasn't going any  
where fast.

This appears to be better, but it seems to be assigning some magic  
behavior to the second argument so it specifies both the value.  Was  
there previous discussion or a bug report filed on this that I missed?

I'm thinking it would be cleaner to support an optional 3 argument to  
emit with { _id:"", _rev:"" }?  The current two argument emit() would  
be the equivalent of emit(key, value, { _id:doc._id, _rev:doc.rev}).






Mime
View raw message