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.198.233 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=SXiNa0AOhpqF6ufEGl2W3xJHA4womNxgBNyW4YqfQBz9/2wwS9HeQWPu01PYvHsj7V
         tNHmmc0HTaIk1wkVMXbEAov77FqY1kAf5+R7cKi+gSLaP4vBnaAeLdOCqarP9yxVIxfK
         0vXXF4cx98Uq6loskHVO01pd2KAC69KxK77IM=
MIME-Version: 1.0
In-Reply-To: <E142B71E-12BB-42A1-9EE3-9C88B41A9E6F@apache.org>
References: <e282921e0902041305v65b0f77eva549c818fb9128c0@mail.gmail.com>
	 <E142B71E-12BB-42A1-9EE3-9C88B41A9E6F@apache.org>
Date: Wed, 4 Feb 2009 16:36:05 -0500
Message-ID: <e2111bbb0902041336w25a71487y2c0f471348f74287@mail.gmail.com>
Subject: Re: view definition _rev behavior
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 Wed, Feb 4, 2009 at 4:16 PM, Damien Katz <damien@apache.org> wrote:
> This would certainly be a nice thing to have, but you can get pretty much
> the same behavior by simply using a new design document id.
>
> -Damien
>

An extension to Damien's idea I just thought of loading the new
_design doc under a different name and generating the views. With a
patch to MOVE we could also rename the view file on disk. Making sure
the swap was atomic could be a PITA though.

>
> On Feb 4, 2009, at 4:05 PM, Chris Anderson wrote:
>
>> Devs,
>>
>> One of the longstanding issues with CouchDB has been, how to handle
>> changes in view definitions.
>>
>> If you are exposing CouchDB view URLs to end users, you don't have the
>> luxury of controlling where applications query, so using a version
>> number in the design doc name is not feasible.
>>
>> The work around I came up with in the last couple of days (no patch,
>> just an idea) is to continue to maintain and serve the existing view
>> index, while the index for the new view definitions comes up to date.
>> (For apps that can't accept this relaxed guarantee, we could have an
>> X-Couch-Wait-For-Latest-View=true header.)
>>
>> The edge case that I'd like to get right, before implementing, is that
>> you may be rolling out other code in the design doc, that depends on
>> the the new view. To get this really slick, we'd want to continue to
>> serve the old design docs attachments, lists, validations, shows,
>> etc., until the new view is ready for queries. That way all the code
>> rolls over at the same time, when the new views are ready.
>>
>> Getting this right is not impossible but will require some thinking.
>> Particularly we want to avoid serving old design docs when the changes
>> don't effect the view index. Also compacting away the old design doc,
>> could be a nasty surprise.
>>
>> I think there could be a big usability payoff here if we get this
>> right - feedback welcome.
>>
>> Chris
>>
>> --
>> Chris Anderson
>> http://jchris.mfdz.com
>
>