On Thu, Aug 25, 2011 at 9:55 AM, Paul Davis <[email protected]> wrote: >> 1. CouchDB has an odd, idiosyncratic, feature where GET queries >> produce side-effects. From HTTP, there are no side-effects, but as you >> can see, GETting a view can spawn couches processes and write files to >> the disk. Perhaps you could add ?stale=ok to all of your queries used >> in production. To my knowledge, stale=ok guarantees that couchjs will >> not be involved in servicing that query. This protects your users from >> seeing map/reduce errors. The down-side is that you must of course >> query the views yourself to keep them current. >> > > No, couchjs will still be required to service reductions. stale=ok > just means you don't have to wait for a possibly lengthy view build.
Thanks for the correction. > Also, "GET's cause side effects" is a bit misleading I think. A GET on > a view by default tries to return data from something equal to or > newer than the current database update_seq. If the current view state > hasn't caught up to the db's update_seq it waits. Classifying this as > "GET's have side effects" is really like saying "GET to a Rails APP > causes side effects because you have to wait for the template to > render." > > For those familiar with internals its quite true that if the indexer > isn't running, a new GET request will trigger an update. But say we > change that so that view updates are tried every N seconds and a GET > itself will never trigger an update but might endure a delay of N-1 > seconds before anything starts happening. You'd be hard pressed to say > that the "GET caused side effects" in that case yet the observable > behavior is the same: "sometimes it takes a while." Yes, I use a sloppy definition. Every query has side effects, since they are logged. But that is a trivial case. So you are right. At any rate, for all the system administrator knows, a GET query can create a new .view file and build a 500GB view which fills up the disk. It's a small detail worth knowing. Day-to-day, it's not that serious of a threat. The main point is that you get more robust and more predictable behavior by using ?stale=ok most of the time, and taking the trouble to update the views independently. In my projects, I have a change count and also time duration threshold. If either are exceeded then it triggers a view refresh on all design documents for that database. -- Iris Couch
