On Fri, Jul 17, 2009 at 2:03 PM, Will Hartung<[email protected]> 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
