Updating views in a production system

3 views
Skip to first unread message

Nadav Samet

unread,
Jun 9, 2009, 2:13:43 AM6/9/09
to us...@couchdb.apache.org
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) ?

If so, is it possible to avoid downtime when adding/editing a view on a
single replica setup?

--
Sincerely yours,
Nadav

Paul Carey

unread,
Jun 9, 2009, 9:28:59 AM6/9/09
to us...@couchdb.apache.org
Hi Nadav

> is it possible to avoid downtime when adding/editing a view on a
> single replica setup?

I deploy in a two-step process that avoids downtime.

1. Create a new design doc that contains all the pre-existing views
plus any new views. Query it, and once the query has returned...
2. Deploy your code that refers to the new design doc.

Paul

Jan Lehnardt

unread,
Jun 14, 2009, 5:58:50 AM6/14/09
to us...@couchdb.apache.org
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
--

Zachary Zolton

unread,
Jul 10, 2009, 1:10:16 PM7/10/09
to us...@couchdb.apache.org
This commit would appear to address the situation in 0.10:

http://github.com/halorgium/couchdb/commit/d3f40115b0323e0ec66ed2fa08adb9852d548003

Adam Kocoloski

unread,
Jul 10, 2009, 2:18:18 PM7/10/09
to us...@couchdb.apache.org
Yep, you got it.

Adam

Zachary Zolton

unread,
Jul 10, 2009, 2:44:07 PM7/10/09
to us...@couchdb.apache.org
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

Zachary Zolton

unread,
Jul 10, 2009, 2:47:50 PM7/10/09
to us...@couchdb.apache.org
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<zachary...@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?
>
>

Chris Anderson

unread,
Jul 10, 2009, 4:19:18 PM7/10/09
to us...@couchdb.apache.org
On Fri, Jul 10, 2009 at 11:47 AM, Zachary
Zolton<zachary...@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)

--
Chris Anderson
http://jchrisa.net
http://couch.io

Adam Kocoloski

unread,
Jul 10, 2009, 4:29:01 PM7/10/09
to us...@couchdb.apache.org

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

Zachary Zolton

unread,
Jul 10, 2009, 4:53:47 PM7/10/09
to us...@couchdb.apache.org
Drat... What's that release date for 0.10, again...!? (^_-)
Reply all
Reply to author
Forward
0 new messages