[stamp] Re: Database entry
- From: Brandon Ripley <Brandon.Ripley@xxxxxxxxxx>
- To: "'stamp@xxxxxxxxxxxxx'" <stamp@xxxxxxxxxxxxx>
- Date: Thu, 9 Feb 2006 12:17:13 -0600
The lock setting is a bit of a pain, but something like it is needed
otherwise every match that has multiple scouters entering data is going to
have 6 discrepancies to fix. I don't think a time lock is too bad to
implement, it is only one more check to add to the where clause.
I think never overwriting data is the best approach for updating data.
Trying to only select the latest entry is a little bit of a pain, I've been
trying to do something like that in another database I created. I think, as
long as we use around MySQL v4.2 or later, it should be possible because the
later versions support nested select statements. So if there are multiple
entries, we grab only the latest entry for statistical purposes.
The admin page will have to display all discrepancies and display an entry
form to enter the scouting data the admin thinks is correct. This would have
to be done for any and all matches with discrepancies. Once an admin creates
the new entry, that entry is the latest and greatest, but someone could
still come in and update the data and create another discrepancy. I could
see this occurring quite often by someone inadvertently clicking submit more
than once or accidentally entering the wrong match number. Once an admin
adds the new entry to fix the discrepancy, it should no longer be displayed
in the discrepancy list, so the select statement will have to look at the
scout for the latest entry and if it is an admin, don't display it on the
discrepancy list. Unfortunately, this method will ignore the case where an
non-admin scout entered data and an admin scout inadvertently overwrote that
data and now nobody is going to double check that discrepancy. Should we add
a discrepancyCleared flag that gets set in each offending entry after an
admin resolves the discrepancy? That way, those entries will not should up
on the discrepancies-to-resolve list.
Aren't corner cases and unintended use fun!?
Brandon
_____
From: Ryan McElroy [mailto:ryan@xxxxxxxxxxxxxxxxx]
Sent: Thursday, February 09, 2006 3:52 AM
To: stamp@xxxxxxxxxxxxx
Subject: [stamp] Re: Database entry
Locks scare me. What if something gets locked and someone walks off? Then
its forever uneditable, or else we put in time limits and that gets ugly
real quick. I like Steven's idea better, but then management becomes a
headache. This is something we should all think about for a little more
time, perhaps, and continue to discuss.
Anyway, another thing -- I think it would be best to move from the (cool
looking) AJAX implementation for six_teams.php to a more traditional
page-load system to fill in all the data. Unless someone has some mad
XML-parsing-in-JavaScript skills, I can imagine 100 different requests going
in each time someone loads one page, opening 100 queries to the db, etc...
Much better in my opinion to manage it all on page load. Thoughts?
~Ryan
Steven Buss wrote:
I think you've got some good ideas.
I think we should keep multiple entries for scouting information, that way
if someone does something malicious, its possible to revert back to old (and
good) data. Instead of updates to existing data, all new data would be
appended to the database. Each entry is linked to the user, and given a
timestamp. The most recent data should be displayed unless its flagged by
an admin, in which case the previous entry is displayed until action is
taken on the offending data.
This brings me to a question, how are we going to assign scouting duties? I
will only be at one of the local competitions, is there a mechanism to
assign matches? Are we going to roll this out at just a few regionals this
year, or try to get to every one? If its just a few it would be easier for
us to coordinate eveyrthing and get the bugs worked out. Comments?
On 2/8/06, Brandon Ripley < <mailto:Brandon.Ripley@xxxxxxxxxx>
Brandon.Ripley@xxxxxxxxxx > wrote:
My suggestions:
Whenever the scouting input page is loaded, it should query the database and
fill out all the values on the webpage with the data stored in the database
for that match and robot. Clicking submit would then overwrite the old data
with the new data.
To make multi-user simultaneous entry work, we need to have a way to
identify what robots each scout is scouting. Adding a scoutLock and lockTime
field to the matchRobotData table could accomplish this. The scoutLock field
would indicate what username is scouting this robot and the time the scout
took out that lock. In order to set the lock, we need to add functionality
to allow scouts to indicate what robots he or she will be scouting. This
could be done by adding a checkbox above each of the six robot scout boxes
on the scouting input page. When the page initially loads, the six scouting
input areas will be grayed out and the scout can only check the select boxes
to indicate what robots he or she will be scouting. Once the scout hits the
"Submit My Robot List" button, the page will reload and the scout can enter
values for those robots. If another scout submits the same robot(s) to be
scouted, his or her page will reload and only the robots not already
accounted for will be available for data entry. Additionally, the scouting
input page should display the username of who is scouting what robots. This
will help solve the problem of forgetting to scout a robot, because an
unscouted robot will not have a scout username assigned to it. Now, if for
some reason, a scout selects to scout a robot and doesn't, someone needs to
be able to get in there and enter the data after the match. This can be
accomplished by only allowing the lock to be valid for a short time, such as
two minutes. (Each time someone tries to submit scouting data, the username
should first be compared to the scoutLock name, if they match, the submit
succeeds. If the usernames are not the same, check the lockTime. If the
current time is later than the lockTime plus the scout lock timeout
constant, allow the submit, otherwise, return an error message stating you
are not scouting this robot.)
To further safeguard the overwriting of scouting data, we could add a
uniqueID field to the matchRobotData table. Each time someone updates that
row, this field would be written with a new random ID. This ID would be
written to a hidden field for each robot in the scouting input page. Upon
submit, the ID stored in the form and the ID in the database would be
compared. If they don't match, someone else updated that robot's data
between the time you loaded the page and the time you changed the data and
hit submit. The scouting input page would display an error message stating
the discrepancy and it would display the robot's score from the database in
the scouting page. The user could then do nothing to keep the score that
someone else entered or else re-enter his/her data for that robot and
overwrite what is in the database.
Got it?!
Brandon
-----Original Message-----
From: Ryan McElroy [mailto:ryan@xxxxxxxxxxxxxxxxx
<mailto:ryan@xxxxxxxxxxxxxxxxx> ]
Sent: Tuesday, February 07, 2006 11:27 PM
To: stamp@xxxxxxxxxxxxx <mailto:stamp@xxxxxxxxxxxxx>
Subject: [stamp] Database entry
I think there is something about the overall design of this app that I am
not understanding. When the match input page comes up, is it supposed to be
filled with the last version of the match info submitted? If we want that to
happen dynamically, someone with more (ie, any) AJAX experience should
probably do it.
Also, what do we want to happen when we submit? Overwrite whatever is there
with the stuff just submitted, or try to intelligently figure out what
should be updated (ie, things with zeros should not be updated?)... I guess
the crucial question is is there single-computer input or multi-computer
input for a single match? If the latter, how are we dealing with
inconsistencies?
Stephen, I haven't taken a look at your database classes, and I don't have
any experience using things of the sort (I'm more of a PHP hacker than a PHP
programmer). So, I'd like your opinion on how helpful you think they will be
in this case, and perhaps the best way to use them (maybe a mini-tutorial?)
Thanks,
~Ryan
--
Steven Buss
steven.buss@xxxxxxxxx <mailto:steven.buss@xxxxxxxxx>
PHP/MySQL programmer
Other related posts:
