On Wed, Jul 15, 2009 at 10: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. >
I think the idea point that most people want the Futon interface is important. In all the discussion over _temp_view no one has ever given an argument of when to use the underlying logic instead of permanent views. Near as I can tell, people just want a clear system for learning and mocking permanent views. >> 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. > On the fence over this. If Futon had a "place to play" type of interface, and the underlying code was just using a couple non-special end points I don't think it'd cause confusion. In fact I would wager that having two different types causes even more confusion than if Futon just had a nifty interface for mocking views. > * They are using the API - in which case a rename to slow-views would seem > to address that problem. > I'd disagree here. Who's to say what any given name will convey to any given user, but if we really want to say "Don't use these in production" the most definitive method would be to delete them. >> 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? > Good call. The Futon replicate N docs to memory would definitely be JS only which would be ungood. It'll also be bad when we add different types of indexers. > Cheers, > > Mark > Paul Davis
