<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#330033" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 1/3/2013 2:43 PM, Brett Cannon
wrote:<br>
</div>
<blockquote
cite="mid:CAP1=2W4FLLkh7gM1HVJXdXiKhh+YPBaFuQ6rLnwP=_cwRcvsAA@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Thu, Jan 3, 2013 at 4:06 PM, Glenn
Linderman <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:v+python@g.nevcal.com" target="_blank">v+python@g.nevcal.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#330033" bgcolor="#FFFFFF">
<div class="im">
<div>On 1/3/2013 12:13 PM, Brett Cannon wrote:<br>
</div>
<blockquote type="cite">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.</blockquote>
<br>
</div>
Well, it sounds like a pretty shaky technology
foundation, if simultaneous updates of a shared data
repository have race conditions.<br>
<br>
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.<br>
<br>
</div>
</blockquote>
<div><br>
</div>
<div style="">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.</div>
</div>
</div>
</div>
</blockquote>
<br>
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 :)<br>
<br>
<blockquote
cite="mid:CAP1=2W4FLLkh7gM1HVJXdXiKhh+YPBaFuQ6rLnwP=_cwRcvsAA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#330033" bgcolor="#FFFFFF"> 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...<br>
</div>
</blockquote>
<div><br>
</div>
<div style="">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.</div>
</div>
</div>
</div>
</blockquote>
<br>
Agreed, the fix, if to be done correctly, belongs in Roundup, from
what I understand of how things are implemented.<br>
<br>
<blockquote
cite="mid:CAP1=2W4FLLkh7gM1HVJXdXiKhh+YPBaFuQ6rLnwP=_cwRcvsAA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div style="">-Brett</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#330033" bgcolor="#FFFFFF"> <br>
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.<br>
<br>
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.<br>
<br>
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.</div>
</blockquote>
<div><br>
</div>
<div> </div>
</div>
</div>
</div>
</blockquote>
<br>
</body>
</html>