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 19:07:09 GMT
that is very cool, thanks!

Do you happen to know if there are any deployment tools that already 
support this?


30.11.2011 20.49, Robert Newson kirjoitti:
> CouchDB takes the md5 of the code of your functions to derive the
> filename. Thus, two identical views map to the same file, allowing the
> neat trick of prebuilding views by using a temporary design document.
> B.
> On 30 November 2011 18:36, Niklas Närhinen<>  wrote:
>> 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..
>> Niklas
>> 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