On Wed, Feb 4, 2009 at 4:16 PM, Damien Katz <[email protected]> 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 > >
