Bug #4263
closed
Execution pool is not really an array
100%
Description
I took a closer look at the execution pool that each task possesses as a member variable. It is meant to be an array of task executions. I guess the original thinking was that there could be several executions (i.e. with different start times, end times, type (single run/recurring) and frequencies) for a given task class, and that all those executions would be stored in the same DB record. I guess it would have meant there would only ever be a single record per task class.
This is not the way it is currently implemented in the BE module. There's no way to add more than one execution in the execution pool. And I think this is just as well, as it would make it very complicated to manage in the BE interface. It's better to have a separate database record for each execution type/frequency/etc. of a given class.
This would mean that the execution pool doesn't need to be an array. Changing this would be a rather important change and maybe it's a bit late to do it. OTOH the Scheduler is still not committed to Core and it would be the right moment to still change that.
Opinions? Please.
Updated by Ingo Renner over 15 years ago
Francois Suter wrote:
This is not the way it is currently implemented in the BE module. There's no way to add more than one execution in the execution pool. And I think this is just as well, as it would make it very complicated to manage in the BE interface. It's better to have a separate database record for each execution type/frequency/etc. of a given class.
agreed
Updated by Francois Suter over 15 years ago
- Status changed from New to Accepted
- Assignee set to Francois Suter
This is the opportunity to add an API to set the execution parameters, rather than have all these calls to $task->execution->setInterval(), etc.
Updated by Francois Suter over 15 years ago
This is the opportunity to add an API to set the execution parameters, rather than have all these calls to $task->execution->setInterval(), etc.
...which already exists actually tx_scheduler_Task::registerSingleExecution() and tx_scheduler_Task::registerRecurringExecution() ;-)
But this is leading to a lot of cleanup in next execution time calculation, which was really messy.
Updated by Francois Suter about 15 years ago
- Status changed from Accepted to Resolved
- % Done changed from 0 to 100
Solved in r1125
Note that this represents a major change of API. As far as I could test, everything is running ok. Existing registered tasks have to be deleted, since serialized task objects will not match anymore.
Updated by Francois Suter over 12 years ago
- Status changed from Resolved to Closed
Updated by Michael Stucki almost 11 years ago
- Project changed from 739 to TYPO3 Core
- Category changed from scheduler to scheduler