On Sun, Jan 4, 2009 at 11:10 AM, Christopher Lenz <[email protected]> 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. 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
>

Little late, but I'm going to throw my hat in with cmlenz's. I caught
the tail end of the IRC conversation and mentioned _dev_views or
_debug_views and no one seemed to think about the actual implications.
As German Chris pointed out, 'slow views' implies a 'fast views'.

That said, I'm all for renaming/removing/disabling the temp view
system. Its something that was intended as a testing system and should
only be used as such. Making that obvious to newer users should be a
priority. I just don't think '_slow_views' has that immediate
connotation.

HTH,
Paul Davis

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

Reply via email to