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 Fri, 18 Sep 2009 03:44:16 GMT
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 Anderson

View raw message