Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-Id: <E142B71E-12BB-42A1-9EE3-9C88B41A9E6F@apache.org>
From: Damien Katz <damien@apache.org>
To: dev@couchdb.apache.org
In-Reply-To: <e282921e0902041305v65b0f77eva549c818fb9128c0@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: view definition _rev behavior
Date: Wed, 4 Feb 2009 16:16:20 -0500
References: <e282921e0902041305v65b0f77eva549c818fb9128c0@mail.gmail.com>

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


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