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.
