couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damien Katz <>
Subject Re: renamed _temp_view to _slow_view
Date Tue, 06 Jan 2009 12:51:57 GMT
I'll just go on record as saying I'd rather keep _temp_view and I  
think they should be renamed _slow_views. The biggest problem people  
have with them is they are slow, saying they are temporary doesn't  
tell people they are slow.  Saying they are temporary doesn't say why  
and when you should use them, it gives no indication of the costs. I  
wouldn't have thought this was a problem, but we see time and time  
again people confused by temp views and when to use them. If we put  
the word slow right in the name, it's hard for people to misunderstand  
their biggest flaw.

I understand Chris Anderson's objection to slow views in the code,  
they complicate the code while providing nothing significant in a  
production setting. But I also think getting rid of them will  
complicate other areas of the code (like futon) and will have new edge  
cases to address (nothing too serious, but forcing users to create  
design documents just so they can delete shortly after them will  
certainly mean some stray design docs laying around). I'm in favor of  
keeping slow views, I think the benefit they cleanly provide to new  
users is very helpful.


On Jan 6, 2009, at 7:30 AM, Jan Lehnardt wrote:

> On 6 Jan 2009, at 13:24, Christopher Lenz wrote:
>> On 06.01.2009, at 13:04, Jan Lehnardt wrote:
>>> On 6 Jan 2009, at 12:54, Noah Slater wrote:
>>>> On Tue, Jan 06, 2009 at 12:44:24PM +0100, Jan Lehnardt wrote:
>>>>> There is no mechanism in CouchDB that people should use "instead  
>>>>> of MVCC"
>>>>> whereas in most cases people shouldn't use _temp_views at all  
>>>>> and we make the
>>>>> case that we don't really need them at all. Why should we keep  
>>>>> them (other
>>>>> than "because we have them")?
>>>> Being able to easily play/debug with views is presumably a net win.
>>> Via Futon, Chris will prepare a patch that keeps the current  
>>> behaviour.
>>> Other libraries exist (CouchRest), are in the process of being  
>>> updated
>>> (couchdb-python) and can easily be written.
>> I can't say for sure without seeing a more concrete proposal on how  
>> this would be handled, but all the approaches I can imagine would  
>> be quite the hack, leaving such "temp" design docs lying around in  
>> some cases, and causing conflict errors when you somehow try to do  
>> two or more queries at the same time.
>> And wasn't JChris' suggestion for Futon to prompt for the design/ 
>> view name before running?
> Right, "near current behaviour". We don't want to encourage the wrong
> model in Futon :) Yes this makes thinks a little more complex, but not
> too complex.
> Cheers
> Jan
> --

View raw message