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: 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 16:08:49 GMT
On Thu, Sep 17, 2009 at 11:58 AM, Chris Anderson <jchris@apache.org> wrote:
> 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.
>

I think its more about having a clean API. Using members on the value
does confuse the semantics quite a bit. Pragmatically though, it
wouldn't really change the end result.

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

While the third parameter option is definitely cleaner in terms of API
design, I would have to agree that the cost in terms of added
implementation complexity is a bit forbidding. For the moment without
attempting the implementation I'd leave it as is, but would be in
favor of the three parameter version if someone provides a patch.

Specifically, the added complexity is going to come from how the third
parameter is stored in the btree, how it affects sorting semantics,
and how it relates to reductions. And that's just off the top of my
head without trying to write the code.

Paul Davis

Mime
View raw message