On 1/3/2013 2:43 PM, Brett Cannon wrote:
On Thu, Jan 3, 2013 at 4:06 PM, Glenn Linderman <v+pyt...@g.nevcal.com
<mailto:v+pyt...@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.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
