couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From till <t...@php.net>
Subject Re: [jira] Commented: (COUCHDB-837) Adding stale=partial
Date Wed, 28 Jul 2010 15:28:17 GMT
I think marking it as deprecated would be the way to go. Then clean it
up in the next major (!) release (e.g. 2.0).

Till

On Wed, Jul 28, 2010 at 1:55 PM, Volker Mische <volker.mische@gmail.com> wrote:
> I think deprecating parts of the API after 1.0 is alright, as long if it's
> still there till the next stable major release.
>
> We extend the API, and I don't see a difference between extending it with a
> new value for an existing key and extending it with a new key. Except that
> the latter is cleaner in this case IMHO.
>
> Though I could also live with "stale=update_after".
>
> Cheers,
>  Volker
>
> On 07/28/2010 01:40 PM, Filipe David Manana 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.
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>>>
>>
>>
>>
>
>

Mime
View raw message