couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <>
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 Thu, 17 Sep 2009 23:33:34 GMT
> 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

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

View raw message