incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Zachary Zolton <>
Subject Re: Rapid deployment with CouchDB (problem with view updates)
Date Wed, 30 Nov 2011 15:23:02 GMT

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.


2011/11/30 Niklas Närhinen <>:
> 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

View raw message