A few features to work on for D7 [#931568]

These are the ones I will be working on this week.

1. Auto schedule jobs
2. Re-schedule jobs
3. More ellaborated schedules (day, hour, minute)
4. Provide triggers (or just trigger triggers)
5. Take care of hook_cron_queue_info

Comment	File	Size	Author
#1	screenshot4.png	16.15 KB	Jose Reyero
#1	screenshot5.png	44.18 KB	Jose Reyero

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

Jose Reyero CreditAttribution: Jose Reyero commented 6 October 2010 at 00:09

File	Size
screenshot5.png	44.18 KB
screenshot4.png	16.15 KB

Most of them done, here, http://github.com/josereyero/job_scheduler

Two screenshots

Comment #2

alex_b CreditAttribution: alex_b commented 19 October 2010 at 20:05

Status:

Active

» Needs work

Hey Jose - I just did a review of these changes. Here are me my suggestions / questions:

'job_scheduler_cron_queue_worker' seems to have been registered because: "Providing our own worker has the advantage that we can reschedule the job or take care of cleanup" - I don't see any cleanups in job_scheduler_cron_queue_worker() happening that don't happen in JobScheduler::execute() though. Is this not needed anymore?

auto/jobs handling: I see that there are two new flags in the job scheduler $info array: 'auto' and 'jobs': if 'auto' is present, 'jobs' is expected to contain an array of jobs that can be automatically updated in the schedule. I'd like to use this in Feeds but I see a problem with scalability when the jobs array can get very long (e. g. 3000 sources).

Here is my suggestion:

1. Move the actual rebuilding to hook_cron() - easy, I've already done that: http://github.com/developmentseed/job_scheduler/commit/4080017e9cd6c1930...
2. Replace 'auto' and 'jobs' with 'job callback'
3. Invoke job callback only if actually rebuilding.

Would that work?

Comment #3

alex_b CreditAttribution: alex_b commented 19 October 2010 at 20:07

O, just seeing the drupal_get_schema() in job_scheduler_update_7101 (): http://github.com/developmentseed/job_scheduler/blob/master/job_schedule... - this will break if ever the fields in question change in the original hook (e. g. if they're removed) and somebody uses this upgrade hook.

Comment #4

Jose Reyero CreditAttribution: Jose Reyero commented 19 October 2010 at 22:12

Hi Alex,

About A) yes, we do some clean up, like deleting the job if the callback doesn't exist or in case an exception is thrown out. Also other modules using 'job scheduler' won't need to implement their own queue workers, we save that work for them, if they only need the callback to be called. So, in summary, we save work for other modules + we have some centralized queue handling an more consistent job execution (it always goes through execute/reschedule).

For B), that's the idea of the 'auto' option. Your module can still create its own jobs with auto=FALSE. The auto option may make sense only when we have a known limited list of jobs, not otherwise.

1. About 'rebuilding on cron' I'm not sure I like that option. It introduces unpredictability about when the rebuild happens, that will make bugs really difficult to track, and will let you wondering whether a job is actually running or not and why. Not to mention race conditions when you are rebuilding a job that is running at that very moment (We already have them but they are limited atm). However, for mission critical jobs you can have the module responsible for the jobs checking on cron and/or rebuilding when needed.

2,3. Job callback? Not sure I understand. You mean a callback for creating the jobs not the current 'job execution' callbacks?