couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nathan Stott <>
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:24:36 GMT
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.

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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message