couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <>
Subject Re: RIP Temp Views?
Date Thu, 16 Jul 2009 02:22:14 GMT
On Wed, Jul 15, 2009 at 10:11 PM, Mark Hammond<> 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

View raw message