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 22:57:43 GMT
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.

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

Mime
View raw message