couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <>
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 Mon, 26 Oct 2009 04:36:47 GMT
On Sun, Oct 25, 2009 at 9:24 PM, Nathan Stott <> wrote:
> Sorry for dragging up an old discussion, but I'm curious as to if this
> feature is in 0.10 and if there's documentation about it.  I did some
> searching and could not locate any.

This didn't make the cut for 0.10. The closest documentation is the
test portion of the patch:

> On Thu, Sep 17, 2009 at 10:44 PM, Chris Anderson <> wrote:
>> On Thu, Sep 17, 2009 at 4:33 PM, Paul Davis <>
>> wrote:
>> >> 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.
>> >
>> > By assigning implicit behavior based on the value, its no longer
>> > arbitrary. _rev and now _id are restricted in what they can represent.
>> > For instance, what happens if I emit {"_id": true} with
>> > include_docs=true?
>> >
>> > Think of the third value as a "row options" variable. The two concepts
>> > are basically "We make assumptions about what you wanted based on what
>> > you emit" or "We make no assumptions. You must be precise in what you
>> > want". Being precise is important because it keeps the concept-API
>> > simpler, easier to remember, and easier to reason about.
>> >
>> > It may seem trivial at this point, but what if we add a feature for
>> > following keys instead of id's? And then what if we allow a row to
>> > stop traversal in a breadth first search scheme? Putting these into an
>> > "options variable" makes more sense to me because the concept is that
>> > they affect how the row is interpreted by the server vs what the row
>> > represents to the client.
>> >
>> > Granted that's just the purist argument and it doesn't really mean
>> > anything until there's an implementation. So until someone gives it a
>> > go and puts a patch in JIRA there's no reason to change the current
>> > behavior. I just don't want any future contributors to think this
>> > isn't an idea worth pursuing.
>> >
>> > Paul Davis
>> >
>> I can see the argument now that you describe future features we might
>> build in this manner. However, I still think it's generally OK to muck
>> around in the value namespace, and I wouldn't be opposed to reserving
>> the _ namespace in view values (but I don't think it's necessary).
>> We don't need to be very formal here. If someone is writing a view to
>> take advantage of include_docs special features (or key following, or
>> other future features) they will be able to write their view around
>> the feature implementation.
>> So for hypothetical future instance, if you absolutely must have a
>> view with row values that look like {"_stop":true}, and you don't want
>> to trigger the stop-iteration, then simply don't query the view with
>> ?stop_on_stop=true. If you plan to use the (hypothetical) stop
>> iterator feature, then it's up to you to only have "_stop" : true in
>> your value when you mean it. I don't think this is a big deal, as
>> you'll be writing the map functions around these features anyway, so
>> you can always envelope anything: eg {"my_real_data":{"_stop":true},
>> "_stop" : false}.
>> The bigger question is philosophical. I generally tend to recoil from
>> the purist argument, because once you start to go down that road you
>> face a danger of lots of implementation (and API) complexity for very
>> little practical benefit. I'm not saying I'd vote against a patch
>> here, but I think energy could be put to better use.
>> Chris
>> --
>> Chris Anderson

Chris Anderson

View raw message