Do we have some JIRA allergy? I don't mind a new parameter, whatever its name might be. But it introduces a bigger change in the API, and abandoning "stale" in favour of this new parameter wouldn't be reasonable before at least one major release (2.0, 3.0 whatever, but definitely not 1.x).
I would like to have this (independently of the naming we use) for 1.1. Raise your hands if you're against or in favour of "stale=update_after" (seems meaningful to me). On Wed, Jul 28, 2010 at 7:21 AM, Sebastian Cohnen <[email protected]> wrote: > this is exactly what I tried to say with my comment :) add a new parameter > and keep stale=ok (with its current behavior around for backward > compatibility) > > On 27.07.2010, at 23:47, Volker Mische wrote: > >> I prefer Roberts suggestion. Adding a new parameter that will replace stale >> in the long run, that has understandable values. stale=ok could be kept and >> deprecated and finally replaced in a 1.1/2.0. >> >> update=now|no|after sounds good (though now/no has a high chance of a typo). >> >> Cheers, >> Volker >> >> On 07/27/2010 11:40 PM, Robert Newson wrote: >>> 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. >>>>> >>>> >>>> >>>> >> > > -- Filipe David Manana, [email protected] "Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men."
