On Wed, Nov 30, 2011 at 10:23 PM, Zachary Zolton
<[email protected]> 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>
{"id":"_design/your_ddoc_name","rev":"$new_revision"}
Then delete your temporary doc and perhaps run a view cleanup.
--
Iris Couch
