I'll just go on record as saying I'd rather keep _temp_view and I
think they should be renamed _slow_views. The biggest problem people
have with them is they are slow, saying they are temporary doesn't
tell people they are slow. Saying they are temporary doesn't say why
and when you should use them, it gives no indication of the costs. I
wouldn't have thought this was a problem, but we see time and time
again people confused by temp views and when to use them. If we put
the word slow right in the name, it's hard for people to misunderstand
their biggest flaw.
I understand Chris Anderson's objection to slow views in the code,
they complicate the code while providing nothing significant in a
production setting. But I also think getting rid of them will
complicate other areas of the code (like futon) and will have new edge
cases to address (nothing too serious, but forcing users to create
design documents just so they can delete shortly after them will
certainly mean some stray design docs laying around). I'm in favor of
keeping slow views, I think the benefit they cleanly provide to new
users is very helpful.
-Damien
On Jan 6, 2009, at 7:30 AM, Jan Lehnardt wrote:
On 6 Jan 2009, at 13:24, Christopher Lenz wrote:
On 06.01.2009, at 13:04, Jan Lehnardt wrote:
On 6 Jan 2009, at 12:54, Noah Slater wrote:
On Tue, Jan 06, 2009 at 12:44:24PM +0100, Jan Lehnardt wrote:
There is no mechanism in CouchDB that people should use "instead
of MVCC"
whereas in most cases people shouldn't use _temp_views at all
and we make the
case that we don't really need them at all. Why should we keep
them (other
than "because we have them")?
Being able to easily play/debug with views is presumably a net win.
Via Futon, Chris will prepare a patch that keeps the current
behaviour.
Other libraries exist (CouchRest), are in the process of being
updated
(couchdb-python) and can easily be written.
I can't say for sure without seeing a more concrete proposal on how
this would be handled, but all the approaches I can imagine would
be quite the hack, leaving such "temp" design docs lying around in
some cases, and causing conflict errors when you somehow try to do
two or more queries at the same time.
And wasn't JChris' suggestion for Futon to prompt for the design/
view name before running?
Right, "near current behaviour". We don't want to encourage the wrong
model in Futon :) Yes this makes thinks a little more complex, but not
too complex.
Cheers
Jan
--
