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 23:08:50 GMT
On Thu, Sep 17, 2009 at 3:57 PM, Paul Davis <paul.joseph.davis@gmail.com> wrote:
> On Thu, Sep 17, 2009 at 6:54 PM, Chris Anderson <jchris@apache.org> wrote:
>> 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.
>>
>
> There's plenty of value to adding it. Its just that there's also
> plenty of complexity. I may or may not take a crack at implementing
> it, but for now I agree that its not a priority.

I guess what I'm saying is that I think the include doc "pointer"
belongs in the value, not in some other place. It strikes me as
exactly what emitted values are for, to hold arbitrary data associated
with the key.

Chris

>
>>> Paul Davis
>>>
>>
>>
>>
>> --
>> Chris Anderson
>> http://jchrisa.net
>> http://couch.io
>>
>



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

Mime
View raw message