On 06.01.2009, at 03:36, Chris Anderson wrote:
On Mon, Jan 5, 2009 at 2:06 PM, Christopher Lenz <[email protected]>
wrote:
So, um, can we get this change backed out?
+1 on deleting the feature altogether. It's parallel code in places
and doesn't provide any functionality.
-0, personally I'd prefer just changing the name back to _temp_view.
The "Dropping temp views" thread didn't get much support for removing
temp views AFAICT. In my opinion, temp views are a very convenient way
for playing with view code in small databases (and are just as fast/
slow as permanent view for that purpose). Especially when you're new
to CouchDB and just want to get familiar with how map/reduce functions
work in various cases, whether it's from Futon, Javascript or some
client lib. Having to deal with design docs for such experimentation
purposes adds a bit of a code/mental overhead that's not required by
temp views.
You do have a point about the code duplication required for temp
views, but maybe a bit of refactoring could help here, too?
Backing out the change doesn't bother me. I don't feel strongly about
what it's called, although I don't think slow_view is an inappropriate
name, considering the support requests we receive that turn out to be
solved by saying "don't use temp views."
How many such support requests do we get? This is really a matter of
understanding the very basics of CouchDB, so a simple RTFM is entirely
appropriate in such cases IMO. And maybe changing the tone of the
corresponding docs to more strongly and obviously discourage the use
of temp views in production code.
As far as dropping the feature, Futon could be changed so that it
appear no differently, by automatically creating design docs for temp
views, when the run button is used. Prompting for the design doc name
at that point would be the perfect place for a warning about the
potential cost and time to run.
I'll volunteer to write the patch. I've already worked through how to
patch the db.query function in couch_tests.js, which relies on temp
views. Having it generate a design doc for each query would be
trivial, and transparent to the user.
Would it delete the design doc before returning? How is the name of
the design/view chosen, and how would it work with >=2 clients trying
to perform a db.query() at the same time?
Cheers,
--
Christopher Lenz
cmlenz at gmx.de
http://www.cmlenz.net/
