You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Scheduled tasks currently only work with Functions, but we also want them to support workflows. In order to do this, we'll want to move away from having a direct foreign key to Function on the ScheduledTask model and instead have a more general foreign key setup (separately record the id and model of the related object).
Django's contenttypes framework, and specifically the GenericForeignKey seem designed for this exact scenario. We should look to utilize that as our primary option. If that doesn't work out, implementing a similar concept manually should be pretty straightforward.
In addition to the model changes, the the run_scheduled_task function in core/utils/tasking.py will need to be updated so that it creates either a WorkflowRun or a Task depending on the related object of the ScheduledTask. Alternatively, there's an argument to be made that we should perhaps drop the concept of a WorkflowRun and instead apply this same generic relation concept to Task, where a Task could be either a single function execution or a workflow execution. This approach has several benefits, such as making it much easier to show function and workflow executions in a single, ordered list to get a full picture of all activity. This should be discussed and a separate issue opened as appropriate before proceeding with work on this issue.
The text was updated successfully, but these errors were encountered:
After discussion we are going to pursue the WorkflowRun and Task consolidation, which is now tracked in #242. We should complete that before proceeding with this issue.
Scheduled tasks currently only work with Functions, but we also want them to support workflows. In order to do this, we'll want to move away from having a direct foreign key to Function on the ScheduledTask model and instead have a more general foreign key setup (separately record the id and model of the related object).
Django's contenttypes framework, and specifically the GenericForeignKey seem designed for this exact scenario. We should look to utilize that as our primary option. If that doesn't work out, implementing a similar concept manually should be pretty straightforward.
In addition to the model changes, the the
run_scheduled_task
function incore/utils/tasking.py
will need to be updated so that it creates either aWorkflowRun
or aTask
depending on the related object of the ScheduledTask. Alternatively, there's an argument to be made that we should perhaps drop the concept of aWorkflowRun
and instead apply this same generic relation concept toTask
, where aTask
could be either a single function execution or a workflow execution. This approach has several benefits, such as making it much easier to show function and workflow executions in a single, ordered list to get a full picture of all activity. This should be discussed and a separate issue opened as appropriate before proceeding with work on this issue.The text was updated successfully, but these errors were encountered: