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 Fri, 17 Jul 2009 18:11:33 GMT
On Fri, Jul 17, 2009 at 2:03 PM, Will Hartung<> wrote:
> I like the idea of getting rid of them. If they can be "emulated"
> within Futon, then so much the better.
> The only thing I could suggest is simply providing tooling to make it
> easy for folks to create sub sets of existing DBs. That way it's
> straightforward to encourage development with "permanent" views, but
> not to do it on production DBs, or production volumes.
> The curse of the temp_view is that they persist and "work just like" a
> permanent view, so on the surface folks don't see the difference (and
> in development, there is, almost, no difference).
> As an aside, however, a problem with emulating temp views kind of
> become problematic if/when folks wish to use a different view server
> than JS. Clearly, it's not practical to emulate a Erlang view server
> within a JS couch implementation for development.
> So, that seems to me to point even more to focusing on tooling to make
> it easy and routine to create "development" databases that people can
> mold and form. Or to make, say, implicit view version. (Create a view,
> create it again and the old one is versioned away as view_1 or
> whatever).

This already happens behind the scenes now. Chris Anderson just landed
a patch to name index files after views which allows for zero downtime
upgrades among other things.

> This ends up acting "just like" temp views, but now there's a minor
> Garbage Collection phase to go through and remove the old views.
> And, again, when this is done on a "throw away" instance of the DB,
> it's even less of an issue.
> Regards,
> Will Hartung

In general, this is how I'd shoot for doing it. Give tools to make
slicing a DB easy as well as give Futon a nice interface to
creating/editing/managing design documents.

Paul Davis

View raw message