Niklas, The best way I have found to deal with this is to add these steps to my deployment procedures:
* push the new design doc as _design/your_ddoc_name-prime * query any view from that _design/your_ddoc_name-prime with ?limit=1 * wait for the view query results * push the new design doc again as _design/your_ddoc_name * finally, switch over to the new version of your application code This doesn't require any special knowledge in your clients, since they always query _design/your_ddoc_name. I've used this approach several times and it works like a charm. Yes, you'll have to write a small script, but it's really not that bad. --Zach 2011/11/30 Niklas Närhinen <[email protected]>: > Hi, (tl;dr: How to avoid re-creating the view index > on read if design document modified) > we aren't yet in production with our service that is built on top of > CouchDB. > > But in our alpha stages we have already run into problems regarding design > document deployment and view sequence updates. > > The simplified design document structure is something like: > > _design/customers > views > all > by_sales_person > etc > _design/products > views > all > active > etc > > Now the problem is, we want to evolve quickly and deploy daily to > "production". > > Let's say I add a new view to _design/products to support our upcoming > features - let's assume it's called "in_stock" - and push the design > document to "production". > > Now when existing users try to fetch listing of their products, they have to > wait for the view update for design doc _design/products. > > The real question here is: How can I push to the same design document > frequently without affecting the response times for our users. > > I know there are a few options including: > a) Use new design documents for new views - makes the structure of the > application not that nice. We are expecting tens or hundreds of views > b) Deploy only at night and make sure to re-create view indices - we are > using filtered replication, we would need to 1) have access to all the > databases 2) it's not optimal to deploy at night time and also we are > expecting activity 24/7 > c) query views with stale=ok - this doesn't seem like a good thing to do > within a problem domain where real-time is the key thing to have.. > > The best suggestion I have gotten (from the great IRC-channel), is to have > two (or multiple) versions of every design document, and then in application > logic figure out which one to use. This way I could push the design > document, trigger view index update and then make the applications use the > new design document. > > I can see some shortcomings with this approach, however, including: > a) this would have to be realtime, so either I would have to fetch the > design document to be used before every view query or then have some 404 -> > figure out which view to query > b) or have multiple design document "versions" (like > _design/products_20111130) and hardcode the values in client applications > (webbrowser, native mobile clients, native desktop clients). In the long run > this will be horrible to manage.. > c) no deployment tool supports this, so I would have to self write the > automation of deployment for this, not a big deal but still.. > > So, any other ideas or pointers how to accomplish this? There are so many > great features (with replicaton etc) with couchdb I wouldn't like to have > this single thing ruin it for me.. > > BR, > Niklas Närhinen >
