Hmmm. I'd have imagined this would be on the critical "get this fixed
ASAP" task list for the developers. Is it even on the roadmap? I'd
prefer to avoid building an app that has to choose between making
requests for stale data and potentially waiting an unknown amount of
time for views to update.
Odd that such an issue has remained for so long into the life of
CouchDB.
as
On 23/03/2011, at 2:34 PM, kowsik 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
--
Message protected by MailGuard: e-mail anti-virus, anti-spam and
content filtering.http://www.mailguard.com.au/mg
Click here to report this message as spam:
https://login.mailguard.com.au/report/1BXlqzc02P/15tn9vMQnEeSeRDmMoOocd/0.6
