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 <[email protected]> wrote: > On Thu, Sep 17, 2009 at 4:33 PM, Paul Davis <[email protected]> > 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 > http://jchrisa.net > http://couch.io >
