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