couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <jch...@apache.org>
Subject Re: Its not a JOIN (was 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 15:58:13 GMT
On Thu, Sep 17, 2009 at 7:11 AM, Curt Arnold <carnold@apache.org> wrote:
>
> On Sep 16, 2009, at 11:51 PM, Paul Davis wrote:
>>>>
>>>> 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]}
>>>> };
>>>> }
>
>
> So if I do,
>
> emit(key, doc)
>
> am I specifying the key value and overriding the default document to be
> included since the value would contain _id and _rev members?  They'd have
> the same value, so it wouldn't be detectable, but still no clear boundary
> between the value parts of the parameter and the document part of the
> parameter.
>
>
>>
>>> 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
>> version.
>>
>> Paul Davis
>
>
> A three parameter version would also allow like:
>
> emit(key, value, null);
>
> when you intentionally do not want any documents provided if the user
> specifies include_docs=true.
>
>

I don't see a use case for the 3 parameter version.

If you are writing a view to take advantage of the linking feature,
you would know that you are working to specify the linked doc _id and
perhaps _rev in the value.

If you aren't planning on using include docs, or just want the normal
version of the feature, (include the doc that emitted) then you can
just ignore the whole thing.

Generally I'm leaning strongly toward keep-it-super-simple, as
anything that a user wants to do is possible with the API as it
exists. (If you want to emit a full doc but link to another, you can
stick the emitted doc in an envelope.)

Chris



-- 
Chris Anderson
http://jchrisa.net
http://couch.io

Mime
View raw message