couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niklas Närhinen <>
Subject Re: Rapid deployment with CouchDB (problem with view updates)
Date Wed, 30 Nov 2011 18:36:27 GMT
Hi Zachary and thanks for answering!

I admit my lack of deep knowledge on couchdb internals here, but how 
does couchdb know that it's the same design doc with different name? How 
are the view indices stored? What I'm trying to find out, how does it 
know it has been already indexed with a different name earlier..


30.11.2011 17.23, Zachary Zolton kirjoitti:
> 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<>:
>> 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