Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of paul.joseph.davis@gmail.com
 designates 209.85.210.204 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=oaDk8qHel8T1z2lKZZ5HL7/jhclmd5AuT8zu7kQ1h6Vwec8tkaUcJ5kasowCojPuYi
         HDWdjfXmj+BUKl+mMElCD5jCmf65DBhwnBIMtf81XQlyjQytOZFWaoSAbl8tWmkhX1kN
         JCyM2GBoBjke14vMtSQU6cDJGuxGOEEPJZUp8=
MIME-Version: 1.0
In-Reply-To: <e282921e0907171122m259feecey3e25a2148126300e@mail.gmail.com>
References: <3915c69d0907171103o277b47c2r4fc4ce22cc3fa6be@mail.gmail.com>
	 <e2111bbb0907171111k35e0015ey3005b1c1ee87fce0@mail.gmail.com>
	 <e282921e0907171122m259feecey3e25a2148126300e@mail.gmail.com>
Date: Fri, 17 Jul 2009 14:41:32 -0400
Message-ID: <e2111bbb0907171141x2da7f80dt9673560e33d7d161@mail.gmail.com>
Subject: Re: RIP Temp Views?
From: Paul Davis <paul.joseph.davis@gmail.com>
To: dev@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On Fri, Jul 17, 2009 at 2:22 PM, Chris Anderson<jchris@apache.org> wrote:
> On Fri, Jul 17, 2009 at 11:11 AM, Paul Davis<paul.joseph.davis@gmail.com> wrote:
>> On Fri, Jul 17, 2009 at 2:03 PM, Will Hartung<willh@mirthcorp.com> 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.
>>
>
>
> I don't hear anyone protesting. I think as long as we keep the ability
> to play with views easily in Futon (and add some replication helpers
> for "random" subsets) no one will miss temp views.
>
> It'd be nice to have them stripped out by the end of the month, but
> that's gonna be a fair amount of Futon work. Anyone feel up to it?
>
> Chris
>
> --
> Chris Anderson
> http://jchrisa.net
> http://couch.io
>

I volunteer to delete lots of code in the inernals if someone can give
us Futon awesomeness. Like Chris says, this won't happen till Futon
gets upgrades and my JavaScript fu is embarrassingly weak so patches
*please*.

Paul Davis