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 Sun, 04 Jan 2009 21:43:14 GMT

On 4 Jan 2009, at 22:10, Christopher Lenz wrote:

> On 04.01.2009, at 19:38, Jan Lehnardt wrote:
>> switched.
>> we happily break the API pre 0.9 :)
> I'd like to throw in a bit of caution here. I agree that API  
> breakage is totally acceptable prior to 1.0, but it shouldn't be  
> done just for fun.

Sorry, hence the smiley, I never meant to say we break things for fun.  
This is also in no way the reason for this change.

> This renaming of _temp_view to _slow_view is IMHO a bit on the silly  
> side and definitely not worth breaking client code, plus anything  
> written about couchdb outside the space we control (blog articles,  
> etc).
> In general, I think that API changes, even at this point, should be  
> done with care. Building a thriving ecosystem of client applications  
> and libraries is going to get pretty tough when people get the  
> perception that things change around arbitrarily for no good reason.

I couldn't agree more.

> But even ignoring backwards compatibility, I'm not a fan of this  
> change. _temp_view makes the difference between temp views and  
> regular views pretty clear in that they are one-off views that don't  
> get stored. Now, if someone doesn't understand that that makes them  
> slow, they better get back to reading the basics about how views in  
> CouchDB work.

The problem is that we can't control where people are learning about  
CouchDB. Making the API "speak" is a good idea here. Although, I'd +1  
the removal of temp views.

> Also, "slow views" aren't really any slower than, erm, "fast views"  
> when you run either only once. And when are we going to rename / 
> _view to /_fast_view to make it clear that they're "faster"? And are  
> we seriously going to refer to temp views as "slow views" from now  
> on? Really? :P

_slow_views is just pragmatic for  

> So, to summarize, I think this change is misguided, and breaking  
> compatibility for no good reason rubs me the wrong way. This is only  
> slightly offset by the fact that client code shouldn't be using temp  
> views in the first place.

Sorry for giving the reasoning behind this change a wrong direction.  
See the "Dropping _temp_views"-thread on dev@


> Cheers,
> Chris
>> On 4 Jan 2009, at 12:52, Geir Magnusson Jr. wrote:
>>> is it deprecated or switched?
>>> E.g. will _temp_view still work with a message to the log, or is  
>>> it a 404?
>>> On Jan 3, 2009, at 8:20 PM, Chris Anderson wrote:
>>>> Couchers,
>>>> Please note that we've renamed a path in the HTTP api.
>>>> /mydb/_temp_view has been changed to /mydb/_slow_view to discourage
>>>> people from using it on anything other than a debugging basis.  
>>>> Futon
>>>> should work just as it has been, but any 3rd party libraries that  
>>>> make
>>>> use of _temp_view are encouraged to transition to views stored in
>>>> design docs.
>>>> I've gone through the wiki with a quick find/replace (There's a  
>>>> lot of
>>>> good stuff in there I hadn't seen before) so now the wiki is  
>>>> peppered
>>>> with a lot of _slow_views code examples. Anyone who converts  
>>>> those to
>>>> use design docs gets a bonus high five.
> --
> Christopher Lenz
>  cmlenz at

View raw message