On 1/3/2013 2:43 PM, Brett Cannon wrote: > > > > On Thu, Jan 3, 2013 at 4:06 PM, Glenn Linderman <v+python at g.nevcal.com > <mailto:v+python at g.nevcal.com>> wrote: > > On 1/3/2013 12:13 PM, Brett Cannon wrote: >> It is a form so technically nothing is being done incorrectly in >> changing values based on what you submit, whether you view them >> stale or not. > > Well, it sounds like a pretty shaky technology foundation, if > simultaneous updates of a shared data repository have race conditions. > > Certainly leaving a tab open for long periods of time exacerbates > the issue, as it severely extends the definition of > "simultaneous". Without that, the likelihood of people doing > simultaneous updates is seriously reduced, except maybe for bugs > with "hot" discussions. > > > I would argue it is no longer simultaneous and thus not a race > condition. You can't consider a POST transactional based on when the > HTTP GET request for the form completed to when the POST finally occurs. Argue away. it still is a race condition, just a slow race. HTTP is stateless, not transactional, agreed, but when a transaction system is implemented on top of HTTP, it needs to implement transactional semantics itself... or else it is a pretty shaky foundation for a database. The POST is an update, the prior GET started the transaction. This is just the definition of a transaction, so any arguments you have can only claim that Roundup doesn't implement transactions, and the bug tracker is not a database... and if you are right, then it is a pretty shaky foundation for a bug tracker database. I think that is what I said in the first place :) > Jesus' suggestion of a hidden version field would help, but could > be annoying for the case of someone writing a lengthy response, > and having it discarded because the hidden version field is too > old... so care would have to be taken to preserve such responses > when doing the refresh... > > > As I said, this belongs upstream in Roundup and not directly in our > roundup instance for a proper fix. This is beyond schema and it > heading into low-level Roundup POST functionality. Agreed, the fix, if to be done correctly, belongs in Roundup, from what I understand of how things are implemented. > -Brett > > > Another possible implementation would be to track which fields in > the form are actually updated by a submitter... and reject a > submission only if there was a simultaneous update to that field. > > Another possible implementation for fields like nosy, would be to > display the current list, but provide boxes for additions and > deletions, rather than allowing editing. Or maybe just a "remove > me" button for deletions would suffice, with a box for additions. > Then the processing would avoid adding duplicates. > > People shouldn't have to do heroic things with refreshing to > maintain the consistency of the underlying data... database > transaction technology has been around for quite a few years by > now, and is well understood. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20130103/10b1254a/attachment.html>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4