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 <[email protected]>
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
