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:[EMAIL PROTECTED] 
Sent: Wednesday, July 14, 2004 2:02 PM
Subject: Re: [PHP-DB] 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


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

Reply via email to