couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Re: renamed _temp_view to _slow_view
Date Tue, 06 Jan 2009 11:03:16 GMT

On 6 Jan 2009, at 10:04, Christopher Lenz wrote:

>> Backing out the change doesn't bother me. I don't feel strongly about
>> what it's called, although I don't think slow_view is an  
>> inappropriate
>> name, considering the support requests we receive that turn out to be
>> solved by saying "don't use temp views."
> How many such support requests do we get?

Quite a few. I don't know of a single one that was answered
"You are doing it right"

The biggest misconception comes from people learning CouchDB
and not having yet full understood views & parameters for key-
lookups. They often try to filter docs using views like this:

function(doc) {
   if( == "King") {

This could be partially solved by even better documentation, but you
can't expect people to fully understand everything on the first read.
And again, we can't control where people learn about CouchDB, but
we control the API. In the case above, we can't provide reasonable
support to avoid the mistake (after all, maybe that is a valid map
function if `` would be `doc.type`). In the _temp_view-case
we can be proactive about users making the mistake of using them.

I agree that temporary views are useful in development and Chris
volunteered to keep this usefulness in Futon. I'd suggest we put some
extra work into shaping other libraries and tools into making it easier
to work with views (the `couchapp` script that comes with CouchRest
already makes it dead-easy to play with views and a Python version
is in the works).

> This is really a matter of understanding the very basics of CouchDB,  
> so a simple RTFM is entirely appropriate in such cases IMO. And  
> maybe changing the tone of the corresponding docs to more strongly  
> and obviously discourage the use of temp views in production code.

 From the wiki:

   "Temporary views are only good during development. Final code
     should not rely on them as they are very expensive to compute
     each time they get called and they get increasingly slower the
     more data you have in a database. If you think you can't solve
     something in a permanent view that you can solve in an ad-hoc
     view, you might want to reconsider."

This suits your requirements for documentation yet has failed to
discourage their use.

CouchDB is and has been prone to be approached with miscon-
ceptions like "How do I use pattern X that I know from the RDBMS-
world in CouchDB?". Just like we don't auto-swap `startkey` &
`endkey` for `descending=true` for wrong convenience, we shouldn't
keep _temp_views.

View raw message