Awesome, but since I'm still using 0.9 in production, I'll need to do something else in the meantime.
Will stale=ok queries remain performant during the re-indexing imposed by pushing an updated design document? If that's gonna work for me, I'll probably change my deployment strategy to the following: 1) flip the "latency" switch on, in a admin page 2) now all queries use stale=ok 3) push our new design documents 4) "prime" a view for each design document 5) somehow know when Does anyone see glaring problems with this approach? Cheers, Zach On Fri, Jul 10, 2009 at 1:18 PM, Adam Kocoloski<[email protected]> wrote: > Yep, you got it. > > Adam > > On Jul 10, 2009, at 1:10 PM, Zachary Zolton wrote: > >> This commit would appear to address the situation in 0.10: >> >> >> http://github.com/halorgium/couchdb/commit/d3f40115b0323e0ec66ed2fa08adb9852d548003 >> >> >> On Sun, Jun 14, 2009 at 4:58 AM, Jan Lehnardt<[email protected]> wrote: >>> >>> Hi Nadav, >>> >>> On 9 Jun 2009, at 08:13, Nadav Samet wrote: >>> >>>> Hi, >>>> >>>> Whenever I modify a design document of a view or add a new one, I am >>>> query >>>> any of the other views. Is it the expected behavior (on 0.10.0a) ? >>> >>> Yes. >>> >>>> If so, is it possible to avoid downtime when adding/editing a view on a >>>> single replica setup? >>> >>> Not yet, there's a ticket in JIRA that will remind us to allow for the >>> following >>> pattern: >>> >>> Create a new _design/foo2 instead of editing _design/foo. Query >>> _design/foo2 >>> so a new view index is built and then HTTP COPY _design/foo2 to >>> _design/foo >>> and have CouchDB keep using the pre-created index. >>> >>> Cheers >>> Jan >>> -- >>> >>> > >
