couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Smith <>
Subject Re: Rapid deployment with CouchDB (problem with view updates)
Date Thu, 01 Dec 2011 00:39:18 GMT
On Wed, Nov 30, 2011 at 10:23 PM, Zachary Zolton
<> wrote:
> 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.

It works very well, thus it actually works much better than a charm.

Here is a technique to further reduce the chance of a user or software
error: use the COPY request to atomically promote your temporary
design document to the new one.

First, learn the revisions of the old doc ($to) and the new doc ($from). Then,

COPY /db/_design/your_ddoc_name-prime?rev=$from
Destination: _design/your_ddoc_name?rev=$to
<other headers>

HTTP/1.1 201 Created
Etag: $new_revision (basically $to + 1)
<other headers>


Then delete your temporary doc and perhaps run a view cleanup.

Iris Couch

View raw message