[stamp] Re: Database entry
- From: Steven Buss <steven.buss@xxxxxxxxx>
- To: stamp@xxxxxxxxxxxxx
- Date: Wed, 8 Feb 2006 18:24:32 -0500
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 < 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]
> 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
>
>
--
Steven Buss
steven.buss@xxxxxxxxx
PHP/MySQL programmer
Other related posts:
