couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <>
Subject Re: RIP Temp Views?
Date Thu, 16 Jul 2009 03:41:15 GMT
On Wed, Jul 15, 2009 at 7:22 PM, Paul Davis<> wrote:
> 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.

Testing JS views in Futon is one thing, getting a temporary interface
for other languages is more problematic.

Running views against a _decimated database is one solution.

Months ago I suggested an interface where CouchDB would run the views
on the server, but only until N (random) docs had emitted rows. N
would be a query parameter. The argument against it is that I'd be a
non-trivial additional code path, and probably subject to abuses of
its own.

Server side selection of a small random set of documents for view
generation would allow us to host temp views in any language, and keep
them from being slow in most cases, while fulfilling the development
use case. I'm not sure what it's priority should be but as they say:
patches welcome.

As far as the test suite goes, I think the the technique of
automatically creating design documents for queries is the way to go,
although simulating those views in JS totally wins, too, just not for
testing Couch.


Chris Anderson

View raw message