[stamp] Re: Database entry
- From: Steven Buss <steven.buss@xxxxxxxxx>
- To: stamp@xxxxxxxxxxxxx
- Date: Thu, 9 Feb 2006 05:28:14 -0500
I know how to do it all in one request. We can separate the field name from
the data in the returned data by any sort of delimiter, such as | or even
%STAMP%, then one long string is returned and parsed. Its definitely doable
with just one database call. For exampe:
team1|180|color1|red = put "180" into the "team1" field, put "red" into the
"color1" field.
On 2/9/06, Ryan McElroy <ryan@xxxxxxxxxxxxxxxxx> wrote:
>
> 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 < 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
>
>
--
Steven Buss
steven.buss@xxxxxxxxx
PHP/MySQL programmer
Other related posts:
