Hi, Thanks Peter for your incite. I think that I will probably run a cron for the clean-up. With my sloppy approach I see one problem that I just don't see how to overcome. Maybe you can help me clarify it. In the example of Bob, Mary and Barbara that I gave in my last post. If Bob cancels his hold and I reset date_held for mary to the current date, so that she has adiquite time to place her student. If I do that this will put Barbara into the #1 position because she has now put a hold before Mary. With this beig the case, would the best solution be to recursively go through the others holding the student(Mary and Barbara), and set Mary's date_held to now, and Barabara's date_held to a minute after (a time which has most likely has not occurred yet) Mary's. Hope this makes sense. Kind regards, Justin Palmer -----Original Message----- From: Peter Westergaard [mailto:peter@xxxxxxxxxxxxxx] Sent: Wednesday, July 14, 2004 2:02 PM To: php-db@xxxxxxxxxxxxx Subject: Re: Re: Hold System Ah, now I think I understand. Thank you. > 2. A Coordinator can only hold a student while in the #1 position for > a certain amount of time. (I don't have a problem with calculating the > time.The problems are: A. What do I do with the record once there hold > has expired? B. Also what do I do with the other records that are > holding so they get adequate hold times in the number one position?) I would say the largest problem you're facing is that you'll need some sort of timed-job to "clean up" expired holds and kick off the next coordinator's time-window. No change of table structure will eliminate that need. The best you could do without something like cron working for you, is some really clever coding where every time anyone interacts with the database, it processes any outstanding "expiries". Once you have that, however, your "sloppy" approach seems fine to me. You've answered both (A) and (B) in a manner that will result in the behavior you expect, and you're not throwing up any unreasonable obstacles in data retrieval or storage. So it seems like it does the job to me. The only sorts of requirements I can see you missing might be a database-level safety to ensure no student ends up with two holds at the same time through some race condition. For that, you might break your table into REQUESTED_HOLDS and ACTIVE_HOLDS where the later has a unique filter on Student_ID. But doing this means more processing for not a lot of gain. I'd stick with your original idea, if I were implementing this. -P -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
