On Sun, Oct 25, 2009 at 9:24 PM, Nathan Stott <[email protected]> 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: http://svn.apache.org/viewvc?view=revision&revision=815984 > > 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 >> > -- Chris Anderson http://jchrisa.net http://couch.io
