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
<sebastiancoh...@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.trai...@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.
