Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of cmlenz@gmx.de designates
 213.165.64.20 as permitted sender)
Message-Id: <C03D7FCB-4B67-4B7B-ADF3-11D5A2C66F45@gmx.de>
From: Christopher Lenz <cmlenz@gmx.de>
To: user@couchdb.apache.org
In-Reply-To: <1C2DD95B-7687-49E8-9400-8F0D8F5B7002@apache.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: renamed _temp_view to _slow_view
Date: Sun, 4 Jan 2009 22:10:21 +0100
References: <e282921e0901031720s232dc10exa2415e0d6019b566@mail.gmail.com>
 <9964500F-9976-4AFF-B47E-DAFED5295A75@pobox.com>
 <1C2DD95B-7687-49E8-9400-8F0D8F5B7002@apache.org>

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

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

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.

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 gmx.de
   http://www.cmlenz.net/