couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <>
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:51:42 GMT
On Wed, Sep 16, 2009 at 10:26 PM, Curt Arnold <> wrote:
> On Sep 16, 2009, at 5:42 PM, Chris Anderson wrote:
>> On Wed, Sep 16, 2009 at 3:04 PM,  <> wrote:
>>> Author: jchris
>>> Date: Wed Sep 16 22:04:18 2009
>>> New Revision: 815984
>>> URL:
>>> 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  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.

I don't believe I've ever seen that wiki page before. Which is odd
because I watch all wiki edits to try and keep abreast of exactly this
sort of thing.

I would say yes, Chris's patch addresses almost this exactly though.

I don't think I see how this would affect a partitioning scheme. I
guess it could make people more willing to split documents that might
be better served as a single doc, but that'd be the same regardless
with features like multi-key fetch.

> 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?

There wasn't a ticket, but the new bit is only a minor tweak to a
lesser know feature. Using the _rev member of an emitted object comes
from the ?include_docs=true feature. When I wrote that I fretted over
the race condition of pulling a doc revision that was different than
the one that emitted the row. The best answer at the time was "allow
people to specify a _rev" which was all and good.

The new bit just extends that slightly.

> 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}).

I think this is a pretty good idea. Though unless I'm missing
something the implementation difficulty rises noticeably. The only
initial drawback I see is how we explain the semantics of default
behavior. For ?include_docs=true it was simply "current version or
version specified by _rev". Obviously adding _id makes that weirder,
but I'm don't see a more clear explanation with the third parameter

Paul Davis

View raw message