On 16/07/2009 1:57 AM, Jan Lehnardt wrote:
A feature I am not comfortable with is temp views. The approach renaming them with slow views didn't pan out so I'm proposing to get rid of them all together.
I quite like temp views, but in practice, all I'm really after is the nice futon interface for experimentation. As an aside, why didn't it work out to rename them to slow views? I can't imagine it was simply 'too much effort' but removing them completely isn't going to be similar effort.
Just as an example, from today's #couchdb IRC channel: … tahorg__ joined the chat room. … tahorg__: Hi, I'm trying couchdb and I'm having some _heavy_ performances issue jan____: don't use temp views … Down the road, it was temp views. q.e.d.
I'd kinda assumed that most people experiencing performance issues with temp views were using them from futon. I'm obviously unsure about the conversation you refer to, but I see 2 possibilities:
* They are using futon - so removing temp views but replacing them with something different-but-the-same in futon might lead to the same perceptions.
* They are using the API - in which case a rename to slow-views would seem to address that problem.
Here is how we can keep temp view behaviour without temp views: Take a JavaScript implementation and put it into jquery,couch.js that acts as a replication endpoint for a real CouchDB and calculates results based on the user-provided map- and reduce-functions.
How would that work for non-js query servers? Cheers, Mark
