+1 on stale=update_after. While I don't find it that obvious, it can be explained in documentation. It's better to have this in 1.1 that continue arguing. Perhaps in 2.x we would tidy this, but I bet by then no one will care anyway. :)
B. On Wed, Jul 28, 2010 at 12:40 PM, Filipe David Manana <[email protected]> wrote: > 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." >
