You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Chris Anderson <jc...@apache.org> on 2009/01/04 02:20:37 UTC
renamed _temp_view to _slow_view
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.
Chris
--
Chris Anderson
http://jchris.mfdz.com
Re: renamed _temp_view to _slow_view
Posted by Noah Slater <ns...@apache.org>.
On Sun, Jan 04, 2009 at 10:10:21PM +0100, Christopher Lenz wrote:
> 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.
Despite my previous email in the other thread about the benefits of IRC, I would
like to see breaking changes and important design decisions proposed on the
mailing list with at least some informal consensus building.
> 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
I totally agree, I think the new name is a poor choice.
> 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.
Agreed.
--
Noah Slater, http://tumbolia.org/nslater
Re: renamed _temp_view to _slow_view
Posted by Paul Davis <pa...@gmail.com>.
+0.5 (for removing)
I do think the feature is nice for things like testing. Having
actually read and played around with the underlying code, the benefit
to code ratio seems rather small, especially considering that we're
constantly saying "Don't use it".
Paul
On Mon, Jan 5, 2009 at 9:21 PM, Jason Davies <ja...@jasondavies.com> wrote:
>
> On 6 Jan 2009, at 02:36, Chris Anderson wrote:
>
>> On Mon, Jan 5, 2009 at 2:06 PM, Christopher Lenz <cm...@gmx.de> 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.
>
> +1
>
> --
> Jason Davies
>
> www.jasondavies.com
>
>
Re: renamed _temp_view to _slow_view
Posted by Jason Davies <ja...@jasondavies.com>.
On 6 Jan 2009, at 02:36, Chris Anderson wrote:
> On Mon, Jan 5, 2009 at 2:06 PM, Christopher Lenz <cm...@gmx.de>
> 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.
+1
--
Jason Davies
www.jasondavies.com
Re: renamed _temp_view to _slow_view
Posted by Jan Lehnardt <ja...@apache.org>.
On 6 Jan 2009, at 03:36, Chris Anderson wrote:
> On Mon, Jan 5, 2009 at 2:06 PM, Christopher Lenz <cm...@gmx.de>
> 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.
+1
Jan
--
Re: renamed _temp_view to _slow_view
Posted by Benoit Chesneau <bc...@gmail.com>.
On Tue, Jan 6, 2009 at 1:13 PM, Benoit Chesneau <bc...@gmail.com> wrote:
>>
>
> How will automatic deletion of these "temporary" will be handled ? I
> don't see how you could do differently than the current mecanism ?
>
>
+ views
--
- benoît
Re: renamed _temp_view to _slow_view
Posted by Randall Leeds <ra...@gmail.com>.
> > 1. Remove the _temp_view facility completely, because you can use a
> > temporary _design view, at which point you should understand the
> performance
> > implications, and it cleans up the code.
>
+1
> 2. Leave it as _temp_view, because it does the equivalent of view
> > create/query/delete view in a single POST, and you can document the
> > performance issue.
>
+0
> 3. Change it to _slow_view, because compared to _temp_view, the name
> should
> > act as an immediate warning for people who haven't read the
> documentation.
>
-0
I like _temp_view more than _slow_view because the view is not necessarily
slow. It's no slower than a _design doc view the first time you access it.
_temp_view immediately makes me think "this is something which is not meant
to be used repeatedly or permanently, and I should not really use this in an
app."
Really, I think _debug_view comes closest to conveying what I think such
views are actually *for*. _temp_view is closer to _debug_view in connotation
than _slow_view to me.
But really, just remove it altogether seems the wisest solution.
-Randall
Re: renamed _temp_view to _slow_view
Posted by Benoit Chesneau <bc...@gmail.com>.
>
> 1. Remove the _temp_view facility completely, because you can use a
> temporary _design view, at which point you should understand the performance
> implications, and it cleans up the code.
>
+0
>
> 2. Leave it as _temp_view, because it does the equivalent of view
> create/query/delete view in a single POST, and you can document the
> performance issue.
>
+1
>
> 3. Change it to _slow_view, because compared to _temp_view, the name should
> act as an immediate warning for people who haven't read the documentation.
>
-1
>
- benoît
Re: renamed _temp_view to _slow_view
Posted by Noah Slater <ns...@apache.org>.
On Thu, Jan 08, 2009 at 02:32:51PM +1030, Antony Blakey wrote:
>
> On 08/01/2009, at 2:26 PM, Noah Slater wrote:
>
>> Heh heh. Just for clarification, the Apache voting system uses:
>>
>> -1 -0 +0 +1
>
> In a extraordinary display of contortionist talent, I have spanked my
> own arse, and promise to stick to approved integers from this point
> onwards.
Fill in a G37 form from the Ministry of Approved Integers for any exceptions.
--
Noah Slater, http://tumbolia.org/nslater
Re: renamed _temp_view to _slow_view
Posted by Antony Blakey <an...@gmail.com>.
On 08/01/2009, at 2:26 PM, Noah Slater wrote:
> Heh heh. Just for clarification, the Apache voting system uses:
>
> -1 -0 +0 +1
In a extraordinary display of contortionist talent, I have spanked my
own arse, and promise to stick to approved integers from this point
onwards.
Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
Some defeats are instalments to victory.
-- Jacob Riis
Re: renamed _temp_view to _slow_view
Posted by Noah Slater <ns...@apache.org>.
On Wed, Jan 07, 2009 at 05:47:34PM -1000, Paul Davis wrote:
> 4. Ship CouchDB with _temp_view disabled by default so that people
> must take the action of enabling it for use. (With a nice warning
> right next to the config option.) Then testing can use it
> transparently.
+0
> In other news, if I had known the key combination for pi, my votes
> would be slightly different.
Heh heh. Just for clarification, the Apache voting system uses:
-1 -0 +0 +1
Best,
--
Noah Slater, http://tumbolia.org/nslater
Re: renamed _temp_view to _slow_view
Posted by Antony Blakey <an...@gmail.com>.
On 08/01/2009, at 2:29 PM, Antony Blakey wrote:
> enable_temp_views_that_are_really_really_slow_as_explained_in_the_documentation_that_I_HAVE_READ
> = true
>
> How many people will turn that on and then ask why they are slow :)
Bad, bad i18nist :/
Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
The fact that an opinion has been widely held is no evidence whatever
that it is not utterly absurd.
-- Bertrand Russell
Re: renamed _temp_view to _slow_view
Posted by Antony Blakey <an...@gmail.com>.
On 08/01/2009, at 2:17 PM, Paul Davis wrote:
> 4. Ship CouchDB with _temp_view disabled by default so that people
> must take the action of enabling it for use. (With a nice warning
> right next to the config option.) Then testing can use it
> transparently.
enable_temp_views_that_are_really_really_slow_as_explained_in_the_documentation_that_I_HAVE_READ
= true
How many people will turn that on and then ask why they are slow :)
+1
Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
When I hear somebody sigh, 'Life is hard,' I am always tempted to ask,
'Compared to what?'
-- Sydney Harris
Re: renamed _temp_view to _slow_view
Posted by Paul Davis <pa...@gmail.com>.
On Wed, Jan 7, 2009 at 5:35 PM, Noah Slater <ns...@apache.org> wrote:
> On Thu, Jan 08, 2009 at 02:00:20PM +1030, Antony Blakey wrote:
>> 1. Remove the _temp_view facility completely, because you can use a
>> temporary _design view, at which point you should understand the
>> performance implications, and it cleans up the code.
>
+1
>
>> 2. Leave it as _temp_view, because it does the equivalent of view
>> create/query/delete view in a single POST, and you can document the
>> performance issue.
>
-0
>
>> 3. Change it to _slow_view, because compared to _temp_view, the name
>> should act as an immediate warning for people who haven't read the
>> documentation.
>
-1
4. Ship CouchDB with _temp_view disabled by default so that people
must take the action of enabling it for use. (With a nice warning
right next to the config option.) Then testing can use it
transparently.
+2
In other news, if I had known the key combination for pi, my votes
would be slightly different.
>
> --
> Noah Slater, http://tumbolia.org/nslater
>
Re: renamed _temp_view to _slow_view
Posted by Noah Slater <ns...@apache.org>.
On Thu, Jan 08, 2009 at 02:00:20PM +1030, Antony Blakey wrote:
> 1. Remove the _temp_view facility completely, because you can use a
> temporary _design view, at which point you should understand the
> performance implications, and it cleans up the code.
+0
> 2. Leave it as _temp_view, because it does the equivalent of view
> create/query/delete view in a single POST, and you can document the
> performance issue.
+1
> 3. Change it to _slow_view, because compared to _temp_view, the name
> should act as an immediate warning for people who haven't read the
> documentation.
-1
--
Noah Slater, http://tumbolia.org/nslater
Re: renamed _temp_view to _slow_view
Posted by Chris Anderson <jc...@gmail.com>.
>
> 1. Remove the _temp_view facility completely, because you can use a
> temporary _design view, at which point you should understand the performance
> implications, and it cleans up the code.
+1
CouchDB is only going to get more view-like facilities. Trimming the
fat now could pay dividends going forward, both in code and in API
complexity and learning curve.
> 2. Leave it as _temp_view, because it does the equivalent of view
> create/query/delete view in a single POST, and you can document the
> performance issue.
-0
> 3. Change it to _slow_view, because compared to _temp_view, the name should
> act as an immediate warning for people who haven't read the documentation.
+0
--
Chris Anderson
http://jchris.mfdz.com
Re: renamed _temp_view to _slow_view
Posted by Jan Lehnardt <ja...@apache.org>.
On 21 Jan 2009, at 22:43, Chris Anderson wrote:
> On Wed, Jan 21, 2009 at 1:03 PM, Christopher Lenz <cm...@gmx.de>
> wrote:
>>
>> One thing that's clear is overwhelming objection against the
>> renaming to
>> _slow_view. There seems to be a slight preference towards removing
>> temp
>> views altogether, but I think that may take more discussion.
>>
>> I would suggest we move forward here by first backing out the
>> change to
>> _slow_view.
>
> +1
+1
I'd be okay with forcing the client libs to implement temp views if
we'd document
this pattern thoroughly, provide a reference implementation in
couch.js and maybe
other languages. Since Chris and Chris maintain both the de-facto Ruby
and
Python libs and I have dibs in the preferred PHP lib, that seems
possible. But let's
leave that for another thread.
Cheers
Jan
--
Re: renamed _temp_view to _slow_view
Posted by Chris Anderson <jc...@apache.org>.
On Wed, Jan 21, 2009 at 1:03 PM, Christopher Lenz <cm...@gmx.de> wrote:
> Hey all,
>
> this thread has long completed, so I'm going to tally up the results. For
> every option in (+1, +0, -0, -1) I'll include the number of "votes" in the
> form binding/total, where binding votes are those by PMC members.
>
> On 08.01.2009, at 04:30, Antony Blakey wrote:
>>
>> 1. Remove the _temp_view facility completely, because you can use a
>> temporary _design view, at which point you should understand the performance
>> implications, and it cleans up the code.
>
> +1: 2/6
> +0: 1/2
> -0: 1/1
> -1: 0/0
>
>
>> 2. Leave it as _temp_view, because it does the equivalent of view
>> create/query/delete view in a single POST, and you can document the
>> performance issue.
>
> +1: 2/6
> +0: 1/1
> -0: 1/2
> -1: 1/1
>
>> 3. Change it to _slow_view, because compared to _temp_view, the name
>> should act as an immediate warning for people who haven't read the
>> documentation.
>
> +1: 1/1
> +0: 1/1
> -0: 1/1
> -1: 2/6
>
>
> One thing that's clear is overwhelming objection against the renaming to
> _slow_view. There seems to be a slight preference towards removing temp
> views altogether, but I think that may take more discussion.
>
> I would suggest we move forward here by first backing out the change to
> _slow_view.
+1
This should be an easy change - I'd recommend using find and replace,
rather than SVN trickery, because there's been work done since then. I
don't mind doing it but I have a deep stack right now implementing
view forms. I can do it tomorrow or if anyone else wants to do it now
they are welcome.
Dropping the feature would push the work of creating temporary design
doc to client libraries. I think it would be a simple patch for Futon,
but if language libs want to transparently keep working for users who
want temp-views, they'll need to write some code. (I think they'd be
fine not attempting to implement.)
--
Chris Anderson
http://jchris.mfdz.com
Re: renamed _temp_view to _slow_view
Posted by Christopher Lenz <cm...@gmx.de>.
On 08.01.2009, at 04:30, Antony Blakey wrote:
> On 07/01/2009, at 9:32 PM, Noah Slater wrote:
>> Maybe someone who understands the code issues at hand (i.e. not me)
>> could
>> summarise the options with the pros and cons outlined by the
>> various people in
>> this thread and we could have a small vote on each option to see if
>> there's any
>> clear consensus that we're missing. It might be the case that we
>> all disagree on
>> our main preference but all share a second preference.
>
> Not sure if someone is taking this task on. I'm not, but my
> normalized votes would be:
>
> 1. Remove the _temp_view facility completely, because you can use a
> temporary _design view, at which point you should understand the
> performance implications, and it cleans up the code.
-0
> 2. Leave it as _temp_view, because it does the equivalent of view
> create/query/delete view in a single POST, and you can document the
> performance issue.
+1
> 3. Change it to _slow_view, because compared to _temp_view, the name
> should act as an immediate warning for people who haven't read the
> documentation.
-1
Cheers,
--
Christopher Lenz
cmlenz at gmx.de
http://www.cmlenz.net/
Re: renamed _temp_view to _slow_view
Posted by Christopher Lenz <cm...@gmx.de>.
Hey all,
this thread has long completed, so I'm going to tally up the results.
For every option in (+1, +0, -0, -1) I'll include the number of
"votes" in the form binding/total, where binding votes are those by
PMC members.
On 08.01.2009, at 04:30, Antony Blakey wrote:
> 1. Remove the _temp_view facility completely, because you can use a
> temporary _design view, at which point you should understand the
> performance implications, and it cleans up the code.
+1: 2/6
+0: 1/2
-0: 1/1
-1: 0/0
> 2. Leave it as _temp_view, because it does the equivalent of view
> create/query/delete view in a single POST, and you can document the
> performance issue.
+1: 2/6
+0: 1/1
-0: 1/2
-1: 1/1
> 3. Change it to _slow_view, because compared to _temp_view, the name
> should act as an immediate warning for people who haven't read the
> documentation.
+1: 1/1
+0: 1/1
-0: 1/1
-1: 2/6
One thing that's clear is overwhelming objection against the renaming
to _slow_view. There seems to be a slight preference towards removing
temp views altogether, but I think that may take more discussion.
I would suggest we move forward here by first backing out the change
to _slow_view. It's been in there way too long considering the lack of
consensus over the change, and moving back and forth on such things is
a real pain for authors of apps and/or libraries that would like to
stay compatible with trunk (for example, I never made the change to
_slow_view in couchdb-python because I was optimistic that the name
wouldn't stick ;) ).
Then, we can start discussing the potential removal of temp views,
preferrably based on a concrete patch.
Cheers,
--
Christopher Lenz
cmlenz at gmx.de
http://www.cmlenz.net/
Re: renamed _temp_view to _slow_view
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Jan 7, 2009, at 10:30 PM, Antony Blakey wrote:
> On 07/01/2009, at 9:32 PM, Noah Slater wrote:
>
>> Maybe someone who understands the code issues at hand (i.e. not me)
>> could
>> summarise the options with the pros and cons outlined by the
>> various people in
>> this thread and we could have a small vote on each option to see if
>> there's any
>> clear consensus that we're missing. It might be the case that we
>> all disagree on
>> our main preference but all share a second preference.
>
> Not sure if someone is taking this task on. I'm not, but my
> normalized votes would be:
>
> 1. Remove the _temp_view facility completely, because you can use a
> temporary _design view, at which point you should understand the
> performance implications, and it cleans up the code.
>
> +1
+1
>
>
> 2. Leave it as _temp_view, because it does the equivalent of view
> create/query/delete view in a single POST, and you can document the
> performance issue.
>
> +0.5
+1
>
>
> 3. Change it to _slow_view, because compared to _temp_view, the name
> should act as an immediate warning for people who haven't read the
> documentation.
>
> -1
-1
>
>
> Antony Blakey
> --------------------------
> CTO, Linkuistics Pty Ltd
> Ph: 0438 840 787
>
> If at first you don’t succeed, try, try again. Then quit. No use
> being a damn fool about it
> -- W.C. Fields
>
Re: renamed _temp_view to _slow_view
Posted by Jan Lehnardt <ja...@apache.org>.
On 8 Jan 2009, at 04:30, Antony Blakey wrote:
> On 07/01/2009, at 9:32 PM, Noah Slater wrote:
>
>> Maybe someone who understands the code issues at hand (i.e. not me)
>> could
>> summarise the options with the pros and cons outlined by the
>> various people in
>> this thread and we could have a small vote on each option to see if
>> there's any
>> clear consensus that we're missing. It might be the case that we
>> all disagree on
>> our main preference but all share a second preference.
>
> Not sure if someone is taking this task on. I'm not, but my
> normalized votes would be:
>
> 1. Remove the _temp_view facility completely, because you can use a
> temporary _design view, at which point you should understand the
> performance implications, and it cleans up the code.
+1
> 2. Leave it as _temp_view, because it does the equivalent of view
> create/query/delete view in a single POST, and you can document the
> performance issue.
-1
> 3. Change it to _slow_view, because compared to _temp_view, the name
> should act as an immediate warning for people who haven't read the
> documentation.
+1 (if we are to keep them and not disable by default)
> 4. Ship CouchDB with _temp_view disabled by default so that people
> must take the action of enabling it for use. (With a nice warning
> right next to the config option.) Then testing can use it
> transparently.
+1 (if we are to keep them)
Cheers
Jan
--
Re: renamed _temp_view to _slow_view
Posted by Antony Blakey <an...@gmail.com>.
On 07/01/2009, at 9:32 PM, Noah Slater wrote:
> Maybe someone who understands the code issues at hand (i.e. not me)
> could
> summarise the options with the pros and cons outlined by the various
> people in
> this thread and we could have a small vote on each option to see if
> there's any
> clear consensus that we're missing. It might be the case that we all
> disagree on
> our main preference but all share a second preference.
Not sure if someone is taking this task on. I'm not, but my normalized
votes would be:
1. Remove the _temp_view facility completely, because you can use a
temporary _design view, at which point you should understand the
performance implications, and it cleans up the code.
+1
2. Leave it as _temp_view, because it does the equivalent of view
create/query/delete view in a single POST, and you can document the
performance issue.
+0.5
3. Change it to _slow_view, because compared to _temp_view, the name
should act as an immediate warning for people who haven't read the
documentation.
-1
Antony Blakey
--------------------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
If at first you don’t succeed, try, try again. Then quit. No use being
a damn fool about it
-- W.C. Fields
Re: renamed _temp_view to _slow_view
Posted by Noah Slater <ns...@apache.org>.
On Tue, Jan 06, 2009 at 08:40:45PM -0800, Chris Anderson wrote:
> As far as outcome, I'm happy with whatever makes the group happy. I'm
> sympathetic to arguments that we can't document our way out of
> _temp_views misuse.
Maybe someone who understands the code issues at hand (i.e. not me) could
summarise the options with the pros and cons outlined by the various people in
this thread and we could have a small vote on each option to see if there's any
clear consensus that we're missing. It might be the case that we all disagree on
our main preference but all share a second preference.
Something like this:
* Option A: Sed justo consequat commodo.
Pros: Nulla facilisi. Quisque ultrices. Donec dictum urna vitae.
Cons: Etiam tincidunt. In leo enim, aliquet in. Luctus eu.
Vote: +1
* Option B: Curabitur scelerisque risus in lectus.
Pros: Nulla facilisi. Quisque ultrices. Donec dictum urna vitae.
Cons: Etiam tincidunt. In leo enim, aliquet in. Luctus eu.
Vote: -0
* Option C: Mauris nec lorem.
Pros: Nulla facilisi. Quisque ultrices. Donec dictum urna vitae.
Cons: Etiam tincidunt. In leo enim, aliquet in. Luctus eu.
Vote: -1
* Option D: Morbi consectetur hendrerit turpis.
Pros: Nulla facilisi. Quisque ultrices. Donec dictum urna vitae.
Cons: Etiam tincidunt. In leo enim, aliquet in. Luctus eu.
Vote: +0
--
Noah Slater, http://tumbolia.org/nslater
Re: renamed _temp_view to _slow_view
Posted by Chris Anderson <jc...@gmail.com>.
> On Tue, Jan 6, 2009 at 6:51 AM, Damien Katz <da...@apache.org> wrote:
>
>> I'll just go on record as saying I'd rather keep _temp_view and I think
>> they should be renamed _slow_views.
Considering that everyone has so many viewpoints on this question, I'm
sorry I was so hasty. I didn't mean to pull the rug out from anyone -
I was just trying to nab some low-hanging fruit that I'd (mistakenly)
thought we had a rough consensus on.
As far as outcome, I'm happy with whatever makes the group happy. I'm
sympathetic to arguments that we can't document our way out of
_temp_views misuse.
Perhaps we could throw a 500 error and cancel the view build if it
starts to take more than 45 seconds, or some user configurable amount
of time (maybe it could even be overridden from the query string...).
That seems like an awful lot of work for something that doesn't really
let you do anything special except shoot yourself in the foot.
>> I'm in favor of keeping slow views, I think the benefit they
>> cleanly provide to new users is very helpful.
I'd like to make the case again that it'd be possible to drop the
feature without changing Futon in any material way. As far as other
libraries, I imagine they'd take an argument giving the design doc
name. As far as handling Update Conflicts, I think that would be up to
the library.
--
Chris Anderson
http://jchris.mfdz.com
Re: renamed _temp_view to _slow_view
Posted by Benoit Chesneau <bc...@gmail.com>.
On Tue, Jan 6, 2009 at 1:04 PM, Jan Lehnardt <ja...@apache.org> 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.
>
> Cheers
> Jan
> --
>
How will automatic deletion of these "temporary" will be handled ? I
don't see how you could do differently than the current mecanism ?
- benoît
Re: renamed _temp_view to _slow_view
Posted by Jeremy Wall <jw...@google.com>.
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
couchdb.
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 <da...@apache.org> 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 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
>> --
>>
>
>
Re: renamed _temp_view to _slow_view
Posted by Damien Katz <da...@apache.org>.
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
> --
Re: renamed _temp_view to _slow_view
Posted by Jan Lehnardt <ja...@apache.org>.
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
--
Re: renamed _temp_view to _slow_view
Posted by Christopher Lenz <cm...@gmx.de>.
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?
Cheers,
--
Christopher Lenz
cmlenz at gmx.de
http://www.cmlenz.net/
Re: renamed _temp_view to _slow_view
Posted by Jan Lehnardt <ja...@apache.org>.
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.
Cheers
Jan
--
Re: renamed _temp_view to _slow_view
Posted by Noah Slater <ns...@apache.org>.
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.
--
Noah Slater, http://tumbolia.org/nslater
Re: renamed _temp_view to _slow_view
Posted by Jan Lehnardt <ja...@apache.org>.
Hi Noah,
On 6 Jan 2009, at 12:24, Noah Slater wrote:
> On Tue, Jan 06, 2009 at 12:03:16PM +0100, Jan Lehnardt wrote:
>> On 6 Jan 2009, at 10:04, Christopher Lenz wrote:
>>> 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.
>>
>> From the wiki:
>>
>> "Temporary views are only good during development. Final code
>> should not rely on them as they are very expensive to compute
>> each time they get called and they get increasingly slower the
>> more data you have in a database. If you think you can't solve
>> something in a permanent view that you can solve in an ad-hoc
>> view, you might want to reconsider."
>>
>> This suits your requirements for documentation yet has failed to
>> discourage their use.
>
> And yet no one is proposing we remove MVCC, because misinterpreting
> this for a
> revision system is by far the biggest and most common mistake I have
> seen. Sometimes I think you just have to provide the documentation
> and point
> people to it when they're banging their heads against the wall. I
> mean, for the
> problem I mentioned we have this:
>
> http://wiki.apache.org/couchdb/Document_revisions
>
> If the temporary views are such a problem, why don't we have:
>
> http://wiki.apache.org/couchdb/Temporary_views
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")?
Cheers
Jan
--
Re: renamed _temp_view to _slow_view
Posted by Noah Slater <ns...@apache.org>.
On Tue, Jan 06, 2009 at 12:03:16PM +0100, Jan Lehnardt wrote:
> On 6 Jan 2009, at 10:04, Christopher Lenz wrote:
>> 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.
>
> From the wiki:
>
> "Temporary views are only good during development. Final code
> should not rely on them as they are very expensive to compute
> each time they get called and they get increasingly slower the
> more data you have in a database. If you think you can't solve
> something in a permanent view that you can solve in an ad-hoc
> view, you might want to reconsider."
>
> This suits your requirements for documentation yet has failed to
> discourage their use.
And yet no one is proposing we remove MVCC, because misinterpreting this for a
revision system is by far the biggest and most common mistake I have
seen. Sometimes I think you just have to provide the documentation and point
people to it when they're banging their heads against the wall. I mean, for the
problem I mentioned we have this:
http://wiki.apache.org/couchdb/Document_revisions
If the temporary views are such a problem, why don't we have:
http://wiki.apache.org/couchdb/Temporary_views
Best,
--
Noah Slater, http://tumbolia.org/nslater
Re: renamed _temp_view to _slow_view
Posted by Jan Lehnardt <ja...@apache.org>.
On 6 Jan 2009, at 10:04, Christopher Lenz wrote:
>> 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?
Quite a few. I don't know of a single one that was answered
"You are doing it right"
The biggest misconception comes from people learning CouchDB
and not having yet full understood views & parameters for key-
lookups. They often try to filter docs using views like this:
function(doc) {
if(doc.author == "King") {
emit(...,...);
}
}
This could be partially solved by even better documentation, but you
can't expect people to fully understand everything on the first read.
And again, we can't control where people learn about CouchDB, but
we control the API. In the case above, we can't provide reasonable
support to avoid the mistake (after all, maybe that is a valid map
function if `doc.author` would be `doc.type`). In the _temp_view-case
we can be proactive about users making the mistake of using them.
I agree that temporary views are useful in development and Chris
volunteered to keep this usefulness in Futon. I'd suggest we put some
extra work into shaping other libraries and tools into making it easier
to work with views (the `couchapp` script that comes with CouchRest
already makes it dead-easy to play with views and a Python version
is in the works).
> 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.
From the wiki:
"Temporary views are only good during development. Final code
should not rely on them as they are very expensive to compute
each time they get called and they get increasingly slower the
more data you have in a database. If you think you can't solve
something in a permanent view that you can solve in an ad-hoc
view, you might want to reconsider."
This suits your requirements for documentation yet has failed to
discourage their use.
CouchDB is and has been prone to be approached with miscon-
ceptions like "How do I use pattern X that I know from the RDBMS-
world in CouchDB?". Just like we don't auto-swap `startkey` &
`endkey` for `descending=true` for wrong convenience, we shouldn't
keep _temp_views.
Re: renamed _temp_view to _slow_view
Posted by Noah Slater <ns...@apache.org>.
On Tue, Jan 06, 2009 at 10:04:14AM +0100, Christopher Lenz wrote:
> On 06.01.2009, at 03:36, Chris Anderson wrote:
>> On Mon, Jan 5, 2009 at 2:06 PM, Christopher Lenz <cm...@gmx.de>
>> 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.
Whoops, my previous vote of +1 was based on a misunderstanding.
I do not think we should remove the feature altogether, and so:
-1 for removing temporary views altogether
+1 for backing out the rename changeset
> 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.
Agreed.
--
Noah Slater, http://tumbolia.org/nslater
Re: renamed _temp_view to _slow_view
Posted by Christopher Lenz <cm...@gmx.de>.
On 06.01.2009, at 03:36, Chris Anderson wrote:
> On Mon, Jan 5, 2009 at 2:06 PM, Christopher Lenz <cm...@gmx.de>
> 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/
Re: renamed _temp_view to _slow_view
Posted by Antony Blakey <an...@gmail.com>.
On 06/01/2009, at 1:06 PM, Chris Anderson wrote:
> On Mon, Jan 5, 2009 at 2:06 PM, Christopher Lenz <cm...@gmx.de>
> 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.
+1
Antony Blakey
--------------------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
Man will never be free until the last king is strangled with the
entrails of the last priest.
-- Denis Diderot
Re: renamed _temp_view to _slow_view
Posted by Noah Slater <ns...@apache.org>.
On Mon, Jan 05, 2009 at 06:36:34PM -0800, Chris Anderson wrote:
> +1 on deleting the feature altogether. It's parallel code in places
> and doesn't provide any functionality.
+1
> 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.
Sounds interesting, great suggestion!
--
Noah Slater, http://tumbolia.org/nslater
Re: renamed _temp_view to _slow_view
Posted by Chris Anderson <jc...@gmail.com>.
On Mon, Jan 5, 2009 at 2:06 PM, Christopher Lenz <cm...@gmx.de> 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.
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."
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.
Patching the jquery.couch.js library, as well as any libraries in
other languages that wanted to avoid breaking "legacy" code, would be
trivial as well.
--
Chris Anderson
http://jchris.mfdz.com
Re: renamed _temp_view to _slow_view
Posted by Christopher Lenz <cm...@gmx.de>.
On 05.01.2009, at 12:31, Antony Blakey wrote:
> How about relying on documentation?
>
> This view may be slow (or not, for a small db). I might use it for
> testing or ad-hoc maintenance. Who knows? The one thing you can say
> for certain is that it is temporary, unlike every other view. That
> is the defining characteristic of this facility, and hence
> _temp_view is the appropriate name.
Agreed.
So, um, can we get this change backed out?
Cheers,
--
Christopher Lenz
cmlenz at gmx.de
http://www.cmlenz.net/
Re: renamed _temp_view to _slow_view
Posted by Michael McDaniel <co...@autosys.us>.
I am in agreement with Antony Blakey's statements below. I was
preparing such a statement when I read the post.
I have worked with multiple software packages (as, certainly,
most of you have) which have a form of "debug=true" and the
accompanying *documentation* counseling against using it except
for testing/debugging.
There are modules in Erlang which have exported funs with
documentation "for debug only".
_temp_view is descriptive, documentation can inform proper useage.
As mentioned in my previous post, I prefer keeping _temp_view
~Michael
On Mon, Jan 05, 2009 at 10:01:28PM +1030, Antony Blakey wrote:
> How about relying on documentation?
>
> This view may be slow (or not, for a small db). I might use it for
> testing or ad-hoc maintenance. Who knows? The one thing you can say for
> certain is that it is temporary, unlike every other view. That is the
> defining characteristic of this facility, and hence _temp_view is the
> appropriate name.
>
> On 05/01/2009, at 9:03 PM, Geir Magnusson Jr. wrote:
>
>> How about _test_view? Kinda gets the point across that it's for
>> testing.
>
> Antony Blakey
> -------------
> CTO, Linkuistics Pty Ltd
> Ph: 0438 840 787
>
> All that is required for evil to triumph is that good men do nothing.
>
>
--
Michael McDaniel
Portland, Oregon, USA
http://trip.autosys.us
http://autosys.us
Re: renamed _temp_view to _slow_view
Posted by Antony Blakey <an...@gmail.com>.
On 05/01/2009, at 10:13 PM, Robert Dionne wrote:
> In the early days of DB2, queries that were know to be slow were
> called ad-hoc and strictly verboten in production code. I can see
> where people my want to keep these, even knowing they are slow.
> Perhaps _ad_hoc_view would bring provide this caution, without
> calling them "slow". As was mentioned, they are all slow the first
> time.
Using a more subtle name for something will only work for english
speakers. Everyone else will rely on the documentation. So the
documentation had better explain this issue very clearly, and hence
the name doesn't really matter.
On the one hand, it doesn't really matter what it's called, although
given that it will be in english it may as well mean something in
english. However I do thing the the underlying reality is that the
view is created only for the duration of the call - modulo the server
keeping it around just in case :), and this is the key differentiator
from permanent views. Temporary is the word that most clearly
describes that characteristic. And while ad-hoc might be the opposite
of 'designed', IMO the use of _design is really a substitute for
_view_definition, rather than describing a characteristic of the thing
e.g. 'this is a designed, not ad-hoc thing'. Or maybe, just maybe, I'm
overthinking this issue?
Antony Blakey
--------------------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
Reflecting on W.H. Auden's contemplation of 'necessary murders' in the
Spanish Civil War, George Orwell wrote that such amorality was only
really possible, 'if you are the kind of person who is always
somewhere else when the trigger is pulled'.
-- John Birmingham, "Appeasing Jakarta"
Re: renamed _temp_view to _slow_view
Posted by Robert Dionne <bo...@gmail.com>.
In the early days of DB2, queries that were know to be slow were
called ad-hoc and strictly verboten in production code. I can see
where people my want to keep these, even knowing they are slow.
Perhaps _ad_hoc_view would bring provide this caution, without
calling them "slow". As was mentioned, they are all slow the first time.
Bob
On Jan 5, 2009, at 6:31 AM, Antony Blakey wrote:
> How about relying on documentation?
>
> This view may be slow (or not, for a small db). I might use it for
> testing or ad-hoc maintenance. Who knows? The one thing you can say
> for certain is that it is temporary, unlike every other view. That
> is the defining characteristic of this facility, and hence
> _temp_view is the appropriate name.
>
> On 05/01/2009, at 9:03 PM, Geir Magnusson Jr. wrote:
>
>> How about _test_view? Kinda gets the point across that it's for
>> testing.
>
> Antony Blakey
> -------------
> CTO, Linkuistics Pty Ltd
> Ph: 0438 840 787
>
> All that is required for evil to triumph is that good men do nothing.
>
>
Re: renamed _temp_view to _slow_view
Posted by Antony Blakey <an...@gmail.com>.
How about relying on documentation?
This view may be slow (or not, for a small db). I might use it for
testing or ad-hoc maintenance. Who knows? The one thing you can say
for certain is that it is temporary, unlike every other view. That is
the defining characteristic of this facility, and hence _temp_view is
the appropriate name.
On 05/01/2009, at 9:03 PM, Geir Magnusson Jr. wrote:
> How about _test_view? Kinda gets the point across that it's for
> testing.
Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
All that is required for evil to triumph is that good men do nothing.
Re: renamed _temp_view to _slow_view
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
How about _test_view? Kinda gets the point across that it's for
testing.
geir
On Jan 5, 2009, at 5:04 AM, Paul Davis wrote:
> On Sun, Jan 4, 2009 at 11:10 AM, Christopher Lenz <cm...@gmx.de>
> 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
>
>>> 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/
>>
>>
Re: renamed _temp_view to _slow_view
Posted by Benoit Chesneau <bc...@gmail.com>.
On Mon, Jan 5, 2009 at 11:04 AM, Paul Davis <pa...@gmail.com> wrote:
> On Sun, Jan 4, 2009 at 11:10 AM, Christopher Lenz <cm...@gmx.de> 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
Re: renamed _temp_view to _slow_view
Posted by Paul Davis <pa...@gmail.com>.
On Sun, Jan 4, 2009 at 11:10 AM, Christopher Lenz <cm...@gmx.de> 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
>> 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/
>
>
Re: renamed _temp_view to _slow_view
Posted by Jan Lehnardt <ja...@apache.org>.
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/
>
>
Re: renamed _temp_view to _slow_view
Posted by Christopher Lenz <cm...@gmx.de>.
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
> 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/
Re: renamed _temp_view to _slow_view
Posted by Jan Lehnardt <ja...@apache.org>.
switched.
we happily break the API pre 0.9 :)
Cheers
Jan
--
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.
>>
>> Chris
>>
>> --
>> Chris Anderson
>> http://jchris.mfdz.com
>
>
Re: renamed _temp_view to _slow_view
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
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.
>
> Chris
>
> --
> Chris Anderson
> http://jchris.mfdz.com