couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <robert.new...@gmail.com>
Subject Re: [jira] Commented: (COUCHDB-837) Adding stale=partial
Date Wed, 28 Jul 2010 11:48:40 GMT
+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
<fdmanana@apache.org> 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
> <sebastiancohnen@googlemail.com> 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<klaus.trainer@web.de>
 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,
> fdmanana@apache.org
>
> "Reasonable men adapt themselves to the world.
>  Unreasonable men adapt the world to themselves.
>  That's why all progress depends on unreasonable men."
>

Mime
View raw message