After re-reading this thread, I see that possibly everyone is referring to other accesses being blocked for a short period of time after a doc update. I should have noticed that was being referred to instead of what I originally meant, which was the blocking when changing to source code for a view.
I understand why one has to wait for an update to be reflected in a view unless you choose to allow reading stale docs. This is common sense. You choose to either wait for the new or accept the old. I can't imagine a third possibility. On Tue, Mar 22, 2011 at 8:42 PM, Mark Hahn <m...@boutiquing.com> wrote: > Just to make it clear, I am only talking about the process that > happens when I change the source code of a view. I wasn't surprised > to see accesses to that view being blocked, but seeing all access to > all views being blocked was stupefying. Why rebuild views that > haven't changed? > > > On Tue, Mar 22, 2011 at 8:34 PM, kowsik <kow...@gmail.com> wrote: >> On Tue, Mar 22, 2011 at 8:28 PM, Andrew Stuart (SuperCoders) >> <andrew.stu...@supercoders.com.au> wrote: >>> This one seems hard to believe - is it true that CouchDB blocks the server >>> whilst updating views? >>> >>> View updates can be alot of work for a server. >>> >>> So in reality, queries to the server pause whilst views are updated? >>> >>> This doesn't seem practical for any production usage. >> >> See this blog: >> http://labs.mudynamics.com/2011/03/10/blitzio-couchdb-in-production/ >> >> As long as you have a worker of sorts that watches the _changes feed >> to "catch up" on the index, things work great. Just like any other >> piece of software, you have to have some understanding how CouchDB >> works internally. There is a stale=ok view query which will get you >> the older revisions so your UI doesn't block at all. >> >>> Can someone confirm that this is true, that during production a server will >>> block whilst views are updated? >> >> See above. :) Yes, couch doesn't do background view indexing, though I >> tend to agree that if there was an Erlang task of sorts that did this >> automatically, end users can relax even more. >> >>> Does anyone else see this as a major issue or am I missing something? I'm >>> happy to say I have missed the point many times before :-) >>> >>> I'm with Mark - I can't think of any other type of modern server that stops >>> processing to get something else done. >> >> K. >> --- >> http://blitz.io >> http://twitter.com/pcapr >> > > > > -- > Mark Hahn > Website Manager > m...@boutiquing.com > 949-229-1012 >
