On Tue, Apr 18, 2017 at 4:44 AM, James Crate via 4D_Tech < [email protected]> wrote:
> Every time I add some automatic process on the server, I wonder whether > there is either > > a. some built-in functionality for this that I have completely missed > Nope. No cron or cron table. For the world's simplest implementation (and nothing you haven't probably already written yourself in the past): * Run one process on the server to launch cron jobs. I'll call it BackgroundJobRunner for this email. Have it wake up every five minutes, hour, whatever. * Keep a "table" (could be a table, could be an external file or folder of external files, etc.) * Maintain a few bits of data in the job definition: -- Last run datetime -- Next run datetime (more below) -- Run frequency/interval/date - whatever you need however you like -- Job details (what you need to do) -- Etc. * Wake up the BackgroundJobRunner on its own interval. It then scans for jobs that need doing. Let's say that you find three. For each job, 1) Track the time that you started and/or the last run datetime. (Used to calculate the next start time later.) 2) Run the job. 3) Once done, use the scheduling definition from the job to calculate the next run datetime. So, if it's a job that should start at 1:05AM each day, just put down 1:05 of the day following the last time the jobs started. If it's every two hours, calculate that, etc. Datetime? Because midnight. Note: It's a little trickier to handle step #3 neatly if you spawn new processes for each job. But doesn't have to be. Just pass in the job definition 'record' reference. It's just that I don't like the job handling code to know anything about the job scheduling code. If you agree, have the job pass a notification to the BackgroundJobRunner announcing that it's done and when it finished. The BackgroundJobRunner can then invoke/run/be the scheduler to figure out when the next job is. Yeah, it is a bit of a surprise that we each have to roll our own individually, but we do. Then again, it's not hard. Just one process (that can spawn others) and one table. The simple version described above doesn't support all UIs or scheduling types, but it covers all of the common cases that I've encountered. Setting up a UI for the thing is the most complicated part. It’s easy enough to just start a process that does what is necessary, but > to do it simply requires a different process for each kind of schedule > (i.e. every 5 minutes, once per day), and isn’t very elegant. > Building/testing my own code to do this sensibly doesn’t make sense for > just this one system. > Given your background, it would probably take you a couple of hours to knock something out with the basics. But, yeah, date math testing is a nightmare. At least me, but I've got bird taxonomies filling up the parts of my brain where date math should be. ********************************************************************** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:[email protected] **********************************************************************
