couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Zachary Zolton <zachary.zol...@gmail.com>
Subject Re: Updating views in a production system
Date Fri, 10 Jul 2009 18:44:07 GMT
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<kocolosk@apache.org> 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<jan@apache.org> 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
>>> --
>>>
>>>
>
>

Mime
View raw message