couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Lenz <>
Subject Re: renamed _temp_view to _slow_view
Date Tue, 06 Jan 2009 09:04:14 GMT
On 06.01.2009, at 03:36, Chris Anderson wrote:
> On Mon, Jan 5, 2009 at 2:06 PM, Christopher Lenz <>  
> wrote:
>> So, um, can we get this change backed out?
> +1 on deleting the feature altogether. It's parallel code in places
> and doesn't provide any functionality.

-0, personally I'd prefer just changing the name back to _temp_view.

The "Dropping temp views" thread didn't get much support for removing  
temp views AFAICT. In my opinion, temp views are a very convenient way  
for playing with view code in small databases (and are just as fast/ 
slow as permanent view for that purpose). Especially when you're new  
to CouchDB and just want to get familiar with how map/reduce functions  
work in various cases, whether it's from Futon, Javascript or some  
client lib. Having to deal with design docs for such experimentation  
purposes adds a bit of a code/mental overhead that's not required by  
temp views.

You do have a point about the code duplication required for temp  
views, but maybe a bit of refactoring could help here, too?

> 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? 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.

> As far as dropping the feature, Futon could be changed so that it
> appear no differently, by automatically creating design docs for temp
> views, when the run button is used. Prompting for the design doc name
> at that point would be the perfect place for a warning about the
> potential cost and time to run.
> I'll volunteer to write the patch. I've already worked through how to
> patch the db.query function in couch_tests.js, which relies on temp
> views. Having it generate a design doc for each query would be
> trivial, and transparent to the user.

Would it delete the design doc before returning? How is the name of  
the design/view chosen, and how would it work with >=2 clients trying  
to perform a db.query() at the same time?

Christopher Lenz
   cmlenz at

View raw message