You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Zachary Zolton <za...@gmail.com> on 2009/07/10 19:10:16 UTC
Re: Updating views in a production system
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<ja...@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
> --
>
>
Re: Updating views in a production system
Posted by Zachary Zolton <za...@gmail.com>.
Drat... What's that release date for 0.10, again...!? (^_-)
On Fri, Jul 10, 2009 at 3:29 PM, Adam Kocoloski<ko...@apache.org> wrote:
> On Jul 10, 2009, at 4:19 PM, Chris Anderson wrote:
>
>> On Fri, Jul 10, 2009 at 11:47 AM, Zachary
>> Zolton<za...@gmail.com> wrote:
>>>
>>> Argh... accidentally hit "send" too soon~!!
>>>
>>> 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 the indexing has finished
>>> 6) flip the "latency" switch off
>>> 7) now queries should go to the freshly-built indexes!
>>>
>>> Does anyone see glaring problems with this approach?
>>>
>>
>> You can simplify:
>>
>> users hitting _design/foo/_view/bar
>>
>> upload new ddoc to _design/fooX
>>
>> query view at _design/fooX/_view/bar once to trigger generation
>>
>> when it's done, http COPY _design/fooX to _design/foo
>>
>> users querying _design/foo/_view/bar should never see downtime
>>
>> (let me know if this works it's based on a new feature I just added)
>
> But Zach's looking for something that works in 0.9. And Zach, I'm afraid
> your plan won't work there. In my experience your stale=ok queries will
> return 0 rows after you upload the new design doc. Best,
>
> Adam
>
>
Re: Updating views in a production system
Posted by Adam Kocoloski <ko...@apache.org>.
On Jul 10, 2009, at 4:19 PM, Chris Anderson wrote:
> On Fri, Jul 10, 2009 at 11:47 AM, Zachary
> Zolton<za...@gmail.com> wrote:
>> Argh... accidentally hit "send" too soon~!!
>>
>> 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 the indexing has finished
>> 6) flip the "latency" switch off
>> 7) now queries should go to the freshly-built indexes!
>>
>> Does anyone see glaring problems with this approach?
>>
>
> You can simplify:
>
> users hitting _design/foo/_view/bar
>
> upload new ddoc to _design/fooX
>
> query view at _design/fooX/_view/bar once to trigger generation
>
> when it's done, http COPY _design/fooX to _design/foo
>
> users querying _design/foo/_view/bar should never see downtime
>
> (let me know if this works it's based on a new feature I just added)
But Zach's looking for something that works in 0.9. And Zach, I'm
afraid your plan won't work there. In my experience your stale=ok
queries will return 0 rows after you upload the new design doc. Best,
Adam
Re: Updating views in a production system
Posted by Chris Anderson <jc...@apache.org>.
On Fri, Jul 10, 2009 at 11:47 AM, Zachary
Zolton<za...@gmail.com> wrote:
> Argh... accidentally hit "send" too soon~!!
>
> 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 the indexing has finished
> 6) flip the "latency" switch off
> 7) now queries should go to the freshly-built indexes!
>
> Does anyone see glaring problems with this approach?
>
You can simplify:
users hitting _design/foo/_view/bar
upload new ddoc to _design/fooX
query view at _design/fooX/_view/bar once to trigger generation
when it's done, http COPY _design/fooX to _design/foo
users querying _design/foo/_view/bar should never see downtime
(let me know if this works it's based on a new feature I just added)
> —ZZ
>
> On Fri, Jul 10, 2009 at 1:44 PM, Zachary Zolton<za...@gmail.com> wrote:
>> 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?
>>
>>
>> Does anyone see glaring problems with this approach?
>>
>>
>> Cheers,
>>
>> Zach
>>
>>
>> On Fri, Jul 10, 2009 at 1:18 PM, Adam Kocoloski<ko...@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<ja...@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
>>>>> --
>>>>>
>>>>>
>>>
>>>
>>
>
--
Chris Anderson
http://jchrisa.net
http://couch.io
Re: Updating views in a production system
Posted by Zachary Zolton <za...@gmail.com>.
Argh... accidentally hit "send" too soon~!!
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 the indexing has finished
6) flip the "latency" switch off
7) now queries should go to the freshly-built indexes!
Does anyone see glaring problems with this approach?
—ZZ
On Fri, Jul 10, 2009 at 1:44 PM, Zachary Zolton<za...@gmail.com> wrote:
> 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?
>
>
> Does anyone see glaring problems with this approach?
>
>
> Cheers,
>
> Zach
>
>
> On Fri, Jul 10, 2009 at 1:18 PM, Adam Kocoloski<ko...@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<ja...@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
>>>> --
>>>>
>>>>
>>
>>
>
Re: Updating views in a production system
Posted by Zachary Zolton <za...@gmail.com>.
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<ko...@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<ja...@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
>>> --
>>>
>>>
>
>
Re: Updating views in a production system
Posted by Adam Kocoloski <ko...@apache.org>.
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<ja...@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
>> --
>>
>>