I realize it's a bit off-topic, but I wrote my own code management/TDD  
Ruby gem, on top of CouchRest.

http://github.com/zdzolton/cambric/tree/master

Now, I don't have much use for temp view queries--given I can write  
Ruby tests for my JavaScript map-reduce code.

-zdzolton

On Jul 15, 2009, at 9:11 PM, Mark Hammond <skippy.hammond@gmail.com>  
wrote
> 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