Return-Path: 
 <user-return-18981-apmail-couchdb-user-archive=couchdb.apache.org@couchdb.apache.org>
X-Original-To: apmail-couchdb-user-archive@www.apache.org
Delivered-To: apmail-couchdb-user-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 06A5994A8
	for <apmail-couchdb-user-archive@www.apache.org>;
 Thu,  1 Dec 2011 00:40:10 +0000 (UTC)
Received: (qmail 6426 invoked by uid 500); 1 Dec 2011 00:40:08 -0000
Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org
Received: (qmail 6386 invoked by uid 500); 1 Dec 2011 00:40:08 -0000
Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:user-help@couchdb.apache.org>
List-Unsubscribe: <mailto:user-unsubscribe@couchdb.apache.org>
List-Post: <mailto:user@couchdb.apache.org>
List-Id: <user.couchdb.apache.org>
Reply-To: user@couchdb.apache.org
Delivered-To: mailing list user@couchdb.apache.org
Received: (qmail 6378 invoked by uid 99); 1 Dec 2011 00:40:08 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Dec 2011 00:40:08 +0000
X-ASF-Spam-Status: No, hits=-0.0 required=5.0
	tests=RCVD_IN_DNSWL_LOW,SPF_NEUTRAL
X-Spam-Check-By: apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Received: from [209.85.161.180] (HELO mail-gx0-f180.google.com)
 (209.85.161.180)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Dec 2011 00:40:02 +0000
Received: by ggnq1 with SMTP id q1so1840033ggn.11
        for <user@couchdb.apache.org>; Wed, 30 Nov 2011 16:39:40 -0800 (PST)
Received: by 10.68.20.233 with SMTP id q9mr343210pbe.99.1322699980240; Wed, 30
 Nov 2011 16:39:40 -0800 (PST)
MIME-Version: 1.0
Received: by 10.143.91.10 with HTTP; Wed, 30 Nov 2011 16:39:18 -0800 (PST)
In-Reply-To: 
 <CAGnHtbJr9bnyf8NJV1O6HtUan4Xh_y2AArSm=Hrqgr6NLycWjQ@mail.gmail.com>
References: <4ED6233E.3040909@narhinen.net>
 <CAGnHtbJr9bnyf8NJV1O6HtUan4Xh_y2AArSm=Hrqgr6NLycWjQ@mail.gmail.com>
From: Jason Smith <jhs@iriscouch.com>
Date: Thu, 1 Dec 2011 07:39:18 +0700
Message-ID: 
 <CAN-3CBL8wrxcSELXsE5hY7G+Q9H5qHCe7w4PiVP=nWJ6bOn5_A@mail.gmail.com>
Subject: Re: Rapid deployment with CouchDB (problem with view updates)
To: user@couchdb.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Nov 30, 2011 at 10:23 PM, Zachary Zolton
<zachary.zolton@gmail.com> wrote:
> Niklas,
>
> The best way I have found to deal with this is to add these steps to
> my deployment procedures:
>
> =C2=A0* push the new design doc as _design/your_ddoc_name-prime
> =C2=A0* query any view from that _design/your_ddoc_name-prime with ?limit=
=3D1
> =C2=A0* wait for the view query results
> =C2=A0* push the new design doc again as _design/your_ddoc_name
> =C2=A0* 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). Th=
en,

COPY /db/_design/your_ddoc_name-prime?rev=3D$from
Destination: _design/your_ddoc_name?rev=3D$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.

--=20
Iris Couch