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 22:54:08 GMT
On Thu, Sep 17, 2009 at 9:08 AM, Paul Davis <paul.joseph.davis@gmail.com> wrote:
> 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.
>

Yeah let's just punt on that, I don't see any value there. If people
are getting concerned about semantics I'd be fine suggesting we change
the whole thing to be emit(key, {"foo":"bar", "_include_doc" : {"_id"
: "X", "_rev":"1-abc"}}) but that just seems gratuitous and
overthought.

> Paul Davis
>



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

Mime
View raw message