incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Wall <>
Subject Re: renamed _temp_view to _slow_view
Date Tue, 06 Jan 2009 15:13:53 GMT
I've been lurking in this discussion up till now but I thought I'd throw in
my perspective as a maintainer of a CPAN module DB::CouchDB::Schema for

Part of that module package is a script that provides similar functionality
to futon, only from the command line. It uses _temp_view as part of the view
editing workflow to test the result of the view. This is helpful when
developing tools like this. I'd like to keep the feature rather than coding
it to make some kind of document I'll just need to delete later anyway. I
don't have much preference as to the name other than that my code already
uses temp_view and synchronizing a release with couchdb with the change is a
minor annoyance.

Jeremy Wall

On Tue, Jan 6, 2009 at 6:51 AM, Damien Katz <> wrote:

> 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
>>>>>> MVCC"
>>>>>> whereas in most cases people shouldn't use _temp_views at all and
>>>>>> 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
>> --

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message