On Mon, Jan 5, 2009 at 11:04 AM, Paul Davis <[email protected]> wrote: > 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 >
imo if anyone read the doc and understood how views work, the "temp" term in _temp_view was the right term, it build a temporary view, I don't know why this change was absolutely needed. If it cause problem for the future where we could have multiple nodes, why not disable it waiting a better solution ? - benoît
