Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of paul.joseph.davis@gmail.com
 designates 209.85.210.194 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=I4yVcBODEyUwrrg99Lc1n2Vk/GNlq9TdUv4NzSBe2DfZzrz0sg22oqlIyCz+uHKppP
         +DnEj7g1qnmTDNj4vD0u0E7RIeuBfmbZJiOp+BnKxNaLcSLrulrvwjjpaou8vFh1/kNO
         R127zymt6zjilPL3kU483m0uUeIenZZQKPneU=
MIME-Version: 1.0
In-Reply-To: <9764C7A3-E05E-4A1A-9505-8329BD1AE1A3@gmail.com>
References: <20090916220419.9719923888D7@eris.apache.org>
	 <e282921e0909161542h14983c46n5af63a73296fdd2c@mail.gmail.com>
	 <9764C7A3-E05E-4A1A-9505-8329BD1AE1A3@gmail.com>
Date: Thu, 17 Sep 2009 00:51:42 -0400
Message-ID: <e2111bbb0909162151m261e3cefh46683fb5f7d5e809@mail.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
From: Paul Davis <paul.joseph.davis@gmail.com>
To: dev@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wed, Sep 16, 2009 at 10:26 PM, Curt Arnold <curt.arnld@gmail.com> wrote:
>
> On Sep 16, 2009, at 5:42 PM, Chris Anderson wrote:
>
>> On Wed, Sep 16, 2009 at 3:04 PM, =A0<jchris@apache.org> wrote:
>>>
>>> Author: jchris
>>> Date: Wed Sep 16 22:04:18 2009
>>> New Revision: 815984
>>>
>>> URL: http://svn.apache.org/viewvc?rev=3D815984&view=3Drev
>>> 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 hav=
e 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=3D0; i < doc.other_docs.length; i++) {
>> =A0emit([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 describe=
d
> in http://wiki.apache.org/couchdb/Forward_document_references. =A0I was u=
neasy
> about that proposal since it strongly favored using one document per enti=
ty
> when that model may not be the appropriate partitioning scheme, but I nev=
er
> bothered putting my thoughts down since it looked like it wasn't going an=
y
> 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 behavi=
or
> to the second argument so it specifies both the value. =A0Was there previ=
ous
> 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=3Dtrue 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 emi=
t
> with { _id:"", _rev:"" }? =A0The 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=3Dtrue 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
version.

Paul Davis