Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of djc.ochtman@gmail.com
 designates 74.125.82.180 as permitted sender)
MIME-Version: 1.0
Sender: djc.ochtman@gmail.com
From: Dirkjan Ochtman <dirkjan@ochtman.nl>
Date: Tue, 1 May 2012 16:59:58 +0200
Message-ID: 
 <CAKmKYaA3ujAyYa3vW220s3GnoCCmZU5WpoQdSGJHCjYid6debg@mail.gmail.com>
Subject: A slightly crazy idea?
To: dev@couchdb.apache.org
Content-Type: text/plain; charset=UTF-8

Hi all,

It seems like view indexing gets hit for one of two reasons:

1. There are new documents (or document revisions) to index
2. The design document has been updated

Currently, for both cases, the default is to have the view wait until
after all documents (revisions) have been indexed using the latest
design doc contents before returning results. I was wondering if it
might be sensible to keep the indexing the same for the first case,
but default to returning stale results (possibly including using the
previous design doc to index the new documents/revisions) and kick off
a process to regenerate results with the new design doc
(update_after-like). There could be a negative value for stale= to
indicate that the view should wait (i.e. stale=wait).

Rationale: I usually want to wait for indexing new revisions, because
we don't generally add revisions at high speed. However, old views
have generally worked fine for a long time, and it's annoying when
many parts of my app have to wait for the index to regenerate.

Does that make sense? Alternatively, are there other ways to attack
this issue? Maybe I could copy my design doc, update it, hit it, then
move it to the old name when it's done? If that works, perhaps Futon
could make that easier?

Cheers,

Dirkjan