[Python-Dev] Posting frequent spurious changes in bugtracker

[Glenn Linderman]

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>