this could run forever so stale=update_after is as good as any suggestion so far. I say get it on trunk, if anyone feels strongly, there's time before it's in a release.
?update=now (default)|no|later/next/after might be better but breaks back compatibility. B. On Tue, Jul 27, 2010 at 10:36 PM, Klaus Trainer <[email protected]> wrote: > +1 > This one sounds good. It clearly makes obvious the update semantics. > > > On Tue, 2010-07-27 at 17:27 -0400, Filipe Manana (JIRA) wrote: >> [ >> https://issues.apache.org/jira/browse/COUCHDB-837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12892934#action_12892934 >> ] >> >> Filipe Manana commented on COUCHDB-837: >> --------------------------------------- >> >> So, having a: >> >> "stale=update_after" >> >> Anyone against? >> >> > Adding stale=partial >> > -------------------- >> > >> > Key: COUCHDB-837 >> > URL: https://issues.apache.org/jira/browse/COUCHDB-837 >> > Project: CouchDB >> > Issue Type: Improvement >> > Environment: all released and unreleased versions >> > Reporter: Filipe Manana >> > Assignee: Filipe Manana >> > Attachments: stale_partial.patch >> > >> > >> > Inspired by Matthias' latest post, at >> > http://www.paperplanes.de/2010/7/26/10_annoying_things_about_couchdb.html, >> > section "Views are updated on read access", I added a new value to the >> > "stale" option named "partial" (possibly we need to find a better name). >> > It behaves exactly like "stale=ok" but after replying to the client, it >> > triggers a view update in the background. >> > Patch attached. >> > If no one disagrees this isn't a good feature, or suggest a better >> > parameter value name, I'll commit. >> > > >
