Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of jchris@gmail.com designates
 209.85.212.171 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:content-type;
        b=uTjo+jbzgPRTNb68UrfWvbXvPDwc6UhQlFTYwsYX0iPtpwKgl78pfjgaMe0Pomb0hN
         bE2yVdveV/w5cJcTagSsGW99OG0AR1K0eh6TH8V9btk4V00r6bYDhYxpcRdUkZoZRIHX
         px5NUBWG6OlApLhmVyRZkVGq4Kwj+GatMesfY=
MIME-Version: 1.0
Sender: jchris@gmail.com
In-Reply-To: <e2111bbb0909171633u3100a7d8i81bb1ebd8bf7ddd4@mail.gmail.com>
References: <20090916220419.9719923888D7@eris.apache.org>
	 <9764C7A3-E05E-4A1A-9505-8329BD1AE1A3@gmail.com>
	 <e2111bbb0909162151m261e3cefh46683fb5f7d5e809@mail.gmail.com>
	 <E067EF88-4112-4082-A1F3-92747F4FE5B5@apache.org>
	 <e282921e0909170858y3664a9c7uc341fbb5b3a0f07@mail.gmail.com>
	 <e2111bbb0909170908p758ccd2bt44660026fb3fa2e5@mail.gmail.com>
	 <e282921e0909171554m4fa86c58m29a8c039dd40ce14@mail.gmail.com>
	 <e2111bbb0909171557s72bc3a0dya0b0bc71054b97c1@mail.gmail.com>
	 <e282921e0909171608t5d4c3dbo172cce6a9131910f@mail.gmail.com>
	 <e2111bbb0909171633u3100a7d8i81bb1ebd8bf7ddd4@mail.gmail.com>
Date: Thu, 17 Sep 2009 20:44:16 -0700
Message-ID: <e282921e0909172044j241666c2h160ff632420cb246@mail.gmail.com>
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)
From: Chris Anderson <jchris@apache.org>
To: dev@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Sep 17, 2009 at 4:33 PM, Paul Davis <paul.joseph.davis@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