Project

General

Profile

Actions

Bug #4263

closed

Execution pool is not really an array

Added by Francois Suter over 15 years ago. Updated almost 11 years ago.

Status:
Closed
Priority:
Could have
Category:
scheduler
Target version:
-
Start date:
2009-08-17
Due date:
% Done:

100%

Estimated time:
TYPO3 Version:
PHP Version:
Tags:
Complexity:
Is Regression:
Sprint Focus:

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.

Actions #1

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

Actions #2

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.

Actions #3

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.

Actions #4

Updated by Francois Suter over 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.

Actions #5

Updated by Francois Suter over 12 years ago

  • Status changed from Resolved to Closed
Actions #6

Updated by Michael Stucki almost 11 years ago

  • Category set to scheduler
Actions #7

Updated by Michael Stucki almost 11 years ago

  • Project changed from 739 to TYPO3 Core
  • Category changed from scheduler to scheduler
Actions

Also available in: Atom PDF