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)

[Nathan Stott <nr...@gmail.com>]

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 <jc...@apache.org> wrote:

> On Thu, Sep 17, 2009 at 4:33 PM, Paul Davis <pa...@gmail.com>
> 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
>

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)

[Chris Anderson <jc...@apache.org>]

On Sun, Oct 25, 2009 at 9:24 PM, Nathan Stott <nr...@gmail.com> 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 <jc...@apache.org> wrote:
>
>> On Thu, Sep 17, 2009 at 4:33 PM, Paul Davis <pa...@gmail.com>
>> 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