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
> 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
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
--
http://github.com/halorgium/couchdb/commit/d3f40115b0323e0ec66ed2fa08adb9852d548003
Adam
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
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?
>
>
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
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