[stamp] Re: Database entry

  • From: Brandon Ripley <Brandon.Ripley@xxxxxxxxxx>
  • To: "'stamp@xxxxxxxxxxxxx'" <stamp@xxxxxxxxxxxxx>
  • Date: Wed, 8 Feb 2006 08:38:56 -0600

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] 
Sent: Tuesday, February 07, 2006 11:27 PM
To: 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

Other related posts: