Re: [jira] Commented: (COUCHDB-837) Adding stale=partial
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 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. >>> >>> >>> >
Re: CouchDB 1.0 retrospectives
Are you sure you want to unsubscribe this mailing list? Ok Cancel On Tue, Jul 27, 2010 at 10:32 PM, Abdul Hakeem wrote: > Does anyone know how to unsubscribe from this list ? > Cheers, > AH > > -Original Message- > From: Jan Lehnardt [mailto:j...@apache.org] > Sent: 22 July 2010 19:30 > To: dev@couchdb.apache.org > Cc: u...@couchdb.apache.org > Subject: Re: CouchDB 1.0 retrospectives > > > On 15 Jul 2010, at 01:14, Jan Lehnardt wrote: > >> >> On 15 Jul 2010, at 01:11, Will Hartung wrote: >> >>> Heh -- ditto -- I thought someone might aggregate links for a one >>> time post, but not hook me up to some confounded soulless world >>> reaching info bot contraption! :) >> >> I actually subscribe to CouchDB-only feeds (except for Rick Ho's blog >> because it is all awesome) and Damien of course, so it is still very >> selective. I read planet CouchDB every day :) > > Today I added: > > Will Hartung > Klaus Trainer > Randall Leeds > > Anyone else with a CouchDB-only posts feed on his/her blog? > (cc user@ - Looking for blogs to link on http://planet.couchdb.org/) > > Cheers > Jan > -- > > -- Filipe David Manana, fdman...@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."
RE: CouchDB 1.0 retrospectives
Does anyone know how to unsubscribe from this list ? Cheers, AH -Original Message- From: Jan Lehnardt [mailto:j...@apache.org] Sent: 22 July 2010 19:30 To: dev@couchdb.apache.org Cc: u...@couchdb.apache.org Subject: Re: CouchDB 1.0 retrospectives On 15 Jul 2010, at 01:14, Jan Lehnardt wrote: > > On 15 Jul 2010, at 01:11, Will Hartung wrote: > >> Heh -- ditto -- I thought someone might aggregate links for a one >> time post, but not hook me up to some confounded soulless world >> reaching info bot contraption! :) > > I actually subscribe to CouchDB-only feeds (except for Rick Ho's blog > because it is all awesome) and Damien of course, so it is still very > selective. I read planet CouchDB every day :) Today I added: Will Hartung Klaus Trainer Randall Leeds Anyone else with a CouchDB-only posts feed on his/her blog? (cc user@ - Looking for blogs to link on http://planet.couchdb.org/) Cheers Jan --
Re: [jira] Commented: (COUCHDB-837) Adding stale=partial
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 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.
Re: [jira] Commented: (COUCHDB-837) Adding stale=partial
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 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. >> > > >
Re: [jira] Commented: (COUCHDB-837) Adding stale=partial
+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. >
[jira] Commented: (COUCHDB-837) Adding stale=partial
[ 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. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: RFC: Releasing 1.0.1
On Tue, Jul 27, 2010 at 14:09, J Chris Anderson wrote: > > On Jul 27, 2010, at 1:58 PM, Randall Leeds wrote: > >> If there are fixes in here or backported to 0.11 that fix >> cross-version replication issues (I know there were some, but I >> haven't followed it carefully) I propose we make sure that's included >> and cut a 0.11.2 release as well. > > As far as I know (haven't tested) 0.11.1 replicates fine with 1.0 > > It's 0.11.0 that doesn't... > Oh, okay. I did say I wasn't following closely. This sounds good to me :)
Re: RFC: Releasing 1.0.1
On Jul 27, 2010, at 1:58 PM, Randall Leeds wrote: > If there are fixes in here or backported to 0.11 that fix > cross-version replication issues (I know there were some, but I > haven't followed it carefully) I propose we make sure that's included > and cut a 0.11.2 release as well. As far as I know (haven't tested) 0.11.1 replicates fine with 1.0 It's 0.11.0 that doesn't...
Re: RFC: Releasing 1.0.1
If there are fixes in here or backported to 0.11 that fix cross-version replication issues (I know there were some, but I haven't followed it carefully) I propose we make sure that's included and cut a 0.11.2 release as well.
Re: RFC: Releasing 1.0.1
On Jul 27, 2010, at 1:38 PM, Mikeal Rogers wrote: > jchris found an issue in make that wasn't including some of the work i did > in Futon that was in a new file. > > jchris do you have that commit hash handy? > that's all backported. we just need to make sure to include new files in the makefile or they don't get installed. for reference: c30eeebc611adc13203ffa6a2c41d922bcc785e3 Chris > -Mikeal > > On Tue, Jul 27, 2010 at 3:57 PM, Robert Newson wrote: > >> +1 >> >> It's a small change that helps people avoid a broken build. what's not to >> like? >> >> B. >> >> On Tue, Jul 27, 2010 at 8:48 PM, J Chris Anderson >> wrote: >>> >>> On Jul 27, 2010, at 12:46 PM, Noah Slater wrote: >>> Hey, I have been asked to prepare the 1.0.1 release. Before I do that, I would like to build consensus. If there's anything >> you'd like to see in this release, or anything you'd like to see removed, >> now is your time to speak. I'll give this thread a few days to simmer before >> starting the formal voting process. >>> >>> should we backport cd214b23e8129868d4a7020ddafd55a16e496652 ? >>> Check if Erlang has been compiled with crypto support at ./configure >>> >>> Jan committed it, anyone else care to chime in? I frankly have no clue. >>> >>> Chris >>> Thanks, N >>> >>> >>
Re: RFC: Releasing 1.0.1
jchris found an issue in make that wasn't including some of the work i did in Futon that was in a new file. jchris do you have that commit hash handy? -Mikeal On Tue, Jul 27, 2010 at 3:57 PM, Robert Newson wrote: > +1 > > It's a small change that helps people avoid a broken build. what's not to > like? > > B. > > On Tue, Jul 27, 2010 at 8:48 PM, J Chris Anderson > wrote: > > > > On Jul 27, 2010, at 12:46 PM, Noah Slater wrote: > > > >> Hey, > >> > >> I have been asked to prepare the 1.0.1 release. > >> > >> Before I do that, I would like to build consensus. If there's anything > you'd like to see in this release, or anything you'd like to see removed, > now is your time to speak. I'll give this thread a few days to simmer before > starting the formal voting process. > >> > > > > should we backport cd214b23e8129868d4a7020ddafd55a16e496652 ? > > Check if Erlang has been compiled with crypto support at ./configure > > > > Jan committed it, anyone else care to chime in? I frankly have no clue. > > > > Chris > > > >> Thanks, > >> > >> N > > > > >
Re: RFC: Releasing 1.0.1
+1 It's a small change that helps people avoid a broken build. what's not to like? B. On Tue, Jul 27, 2010 at 8:48 PM, J Chris Anderson wrote: > > On Jul 27, 2010, at 12:46 PM, Noah Slater wrote: > >> Hey, >> >> I have been asked to prepare the 1.0.1 release. >> >> Before I do that, I would like to build consensus. If there's anything you'd >> like to see in this release, or anything you'd like to see removed, now is >> your time to speak. I'll give this thread a few days to simmer before >> starting the formal voting process. >> > > should we backport cd214b23e8129868d4a7020ddafd55a16e496652 ? > Check if Erlang has been compiled with crypto support at ./configure > > Jan committed it, anyone else care to chime in? I frankly have no clue. > > Chris > >> Thanks, >> >> N > >
Re: RFC: Releasing 1.0.1
On Jul 27, 2010, at 12:46 PM, Noah Slater wrote: > Hey, > > I have been asked to prepare the 1.0.1 release. > > Before I do that, I would like to build consensus. If there's anything you'd > like to see in this release, or anything you'd like to see removed, now is > your time to speak. I'll give this thread a few days to simmer before > starting the formal voting process. > should we backport cd214b23e8129868d4a7020ddafd55a16e496652 ? Check if Erlang has been compiled with crypto support at ./configure Jan committed it, anyone else care to chime in? I frankly have no clue. Chris > Thanks, > > N
RFC: Releasing 1.0.1
Hey, I have been asked to prepare the 1.0.1 release. Before I do that, I would like to build consensus. If there's anything you'd like to see in this release, or anything you'd like to see removed, now is your time to speak. I'll give this thread a few days to simmer before starting the formal voting process. Thanks, N
[jira] Commented: (COUCHDB-837) Adding stale=partial
[ https://issues.apache.org/jira/browse/COUCHDB-837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12892874#action_12892874 ] Chris Anderson commented on COUCHDB-837: stale=ok was carefully and intentionally chosen by me to reflect the crappy consistency guarantees you get with this query. If it had it to do over again I'd chose stale=meh > 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. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-837) Adding stale=partial
[ https://issues.apache.org/jira/browse/COUCHDB-837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12892827#action_12892827 ] Jason Smith commented on COUCHDB-837: - stale=relaxed was tongue in cheek. I'm not a fan either. As long as we are bikeshedding, stale=ok is itself inferior to stale=true. Doubless `ok` is an Erlang-ism that leaked out into the HTTP API. Why is it include_docs=true but not stale=true? (No reply necessary, just airing my grievances.) > 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. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-837) Adding stale=partial
[ https://issues.apache.org/jira/browse/COUCHDB-837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12892815#action_12892815 ] Sebastian Cohnen commented on COUCHDB-837: -- My first thought was something like: stale=ok&suppress_update=true (I like readable parameter names) But what about keeping stale=ok in its current form for backward compatibility and introduce a new parameter? stale=ok is somewhat understandable (and known), but combining it with this new behavior feels kind of odd to me. This would "free" the mindset and you don't need to construct a new parameter in addition to stale=ok or a new value for the stale param. And no, I don't have a good idea for a name for this case :) > 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. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-837) Adding stale=partial
[ https://issues.apache.org/jira/browse/COUCHDB-837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12892797#action_12892797 ] Volker Mische commented on COUCHDB-837: --- I agree that stale=relaxed doesn't really make clear what it is about. Perhaps: stale=trigger stale=trigger-up stale=trigger-update stale=start-update stale=start-up > 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. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (COUCHDB-837) Adding stale=partial
err, true/false on that last one obv. On Tue, Jul 27, 2010 at 3:29 PM, Robert Newson wrote: > agree with davisp that 'stale=relaxed' isn't intuitive at all. "How > can stale be relaxed?". > > No better idea here either, though. stale=ok has painted us into a > corner. There's not many alternatives to 'ok' that parse well. A > separate parameter might be preferable: update=true/false would > activate the update (or not) and stale=ok would be the flag for > whether the call blocks for the update or not. perhaps better, but > can't be done for 1.x, update=true/false&block_for_update=false/false > would allow the three sane permutations. > > B. > > On Tue, Jul 27, 2010 at 3:20 PM, Paul Joseph Davis (JIRA) > wrote: >> >> [ >> https://issues.apache.org/jira/browse/COUCHDB-837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12892792#action_12892792 >> ] >> >> Paul Joseph Davis commented on COUCHDB-837: >> --- >> >> @Jason - Good point on idempotent GET's >> @Filipe - I don't really like it. There's nothing about "stale=relaxed" that >> in any way indicates what its for. A good test might be to ask #couchdb >> "what does stale=ok do, and if stale=relaxed existed, what would you guess >> it does". Unless someone's been paying attention to this ticket I'd doubt >> that they're going to come up with "its stale=ok but starts a re-indexing >> pass". Then again, I agree with @jchris, I don't have any better ideas so >> its up to you. >> >>> 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. >> >> -- >> This message is automatically generated by JIRA. >> - >> You can reply to this email to add a comment to the issue online. >> >> >
Re: [jira] Commented: (COUCHDB-837) Adding stale=partial
agree with davisp that 'stale=relaxed' isn't intuitive at all. "How can stale be relaxed?". No better idea here either, though. stale=ok has painted us into a corner. There's not many alternatives to 'ok' that parse well. A separate parameter might be preferable: update=true/false would activate the update (or not) and stale=ok would be the flag for whether the call blocks for the update or not. perhaps better, but can't be done for 1.x, update=true/false&block_for_update=false/false would allow the three sane permutations. B. On Tue, Jul 27, 2010 at 3:20 PM, Paul Joseph Davis (JIRA) wrote: > > [ > https://issues.apache.org/jira/browse/COUCHDB-837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12892792#action_12892792 > ] > > Paul Joseph Davis commented on COUCHDB-837: > --- > > @Jason - Good point on idempotent GET's > @Filipe - I don't really like it. There's nothing about "stale=relaxed" that > in any way indicates what its for. A good test might be to ask #couchdb "what > does stale=ok do, and if stale=relaxed existed, what would you guess it > does". Unless someone's been paying attention to this ticket I'd doubt that > they're going to come up with "its stale=ok but starts a re-indexing pass". > Then again, I agree with @jchris, I don't have any better ideas so its up to > you. > >> 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. > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > >
[jira] Commented: (COUCHDB-837) Adding stale=partial
[ https://issues.apache.org/jira/browse/COUCHDB-837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12892792#action_12892792 ] Paul Joseph Davis commented on COUCHDB-837: --- @Jason - Good point on idempotent GET's @Filipe - I don't really like it. There's nothing about "stale=relaxed" that in any way indicates what its for. A good test might be to ask #couchdb "what does stale=ok do, and if stale=relaxed existed, what would you guess it does". Unless someone's been paying attention to this ticket I'd doubt that they're going to come up with "its stale=ok but starts a re-indexing pass". Then again, I agree with @jchris, I don't have any better ideas so its up to you. > 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. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-837) Adding stale=partial
[ https://issues.apache.org/jira/browse/COUCHDB-837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12892783#action_12892783 ] Filipe Manana commented on COUCHDB-837: --- Jason, Seems very reasonable to me, having a stale=relaxed option. Who's in favour of this option? > 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. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Proposal for changes in view server/protocol
On Tue, Jul 27, 2010 at 04:35, Mikeal Rogers wrote: > After some conversations I've had in NYC this week and Mathias' great post > on the 10 biggest issues with CouchDB ( > http://www.paperplanes.de/2010/7/26/10_annoying_things_about_couchdb.html) > I wanted to formally propose some changes to the view server/protocol. > Something I would like to see is a way for an _update function, or some similar function, to handle success vs. collision results when producing a doc. An _update function should be able to compute the resulting doc _id based on the provided input. This is especially useful for directly processing HTML form input. Unfortunately, the _update function has no way of knowing if that id is taken already. It blindly passes the document back to Erlang which might return a (IIRC) 201, or might return 409. I do not know what the best solution is but I wouldn't be surprised if it required a protocol change. -- Jason Smith Couchio Hosting
[jira] Commented: (COUCHDB-837) Adding stale=partial
[ https://issues.apache.org/jira/browse/COUCHDB-837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12892758#action_12892758 ] Jason Smith commented on COUCHDB-837: - stale=relax Or a little tougher for non-native speakers: stale=relaxed I must say I like that stale=ok triggers no writes. It makes CouchDB less complex. If stale=ok triggers background indexing it feels like a white lie that GET is idempotent. If the disk becomes full between two GET stale=ok queries (and only 2 queries, no additional writes), I would not want to see different results, and certainly not a 500. > 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. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-837) Adding stale=partial
[ https://issues.apache.org/jira/browse/COUCHDB-837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12892717#action_12892717 ] Volker Mische commented on COUCHDB-837: --- @Paul: I agree, stale=ok should keep it semantics for off-peak view rebuilding @Simon: First I prefer not cluttering the query string options. Therefore something like stale=butupdate. But there's even a bigger problem: reindex=true doesn't work for me. Think of the default values: - no stale, no reindex parameter => normal behaviour, means reindexing - stale=ok, reindex=true => return stale, but start reindexing - stale=ok, reindex=false => return stale, but don't reindex (current stale=ok behavior) - stale=ok, no reindex parameter => and now? should the default reindex value change to "false" when stale==ok? @Jira: Either you don't have a preview button, or you are so cluttered I can't find it (which isn't better) > 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. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-837) Adding stale=partial
[ https://issues.apache.org/jira/browse/COUCHDB-837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12892713#action_12892713 ] Filipe Manana commented on COUCHDB-837: --- Seems it's hard to reach an alternative that everyone likes :( My personal preferences: 1) Like Chris said, this would be the behaviour of stale=ok (let the view update run on background after serving the client) - big advantage - there's no new query parameter nor value. I don't see any problem with it; 2) Add new value to the stale option (so far I like "lazy" or "once") > 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. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
