Use cases:
The timer will always be of the form "This action will automatically execute x number of seconds after it becomes enabled". If it is later un-enabled (disabled) because another action (e.g. a vote action in the second use casae above) was executed, then the timer will be reset. If the action later becomes enabled, the timer will start anew.
We currently do not have any information on which actions are enabled, and when they're enabled. We will probably need a table, perhaps one just for timed actions, in which a row is created when a timed action is enabled, and the row is deleted again when the state changes.
create table workflow_case_timed_actions( ... -- The number of seconds after having become enabled the action -- will automatically execute timeout_seconds integer ... );
create table workflow_case_timed_actions( case_id integer constraint wf_case_time_act_case_id_nn not null constraint wf_case_time_act_case_id_fk references workflow_cases(case_id) on delete cascade, action_id integer constraint wf_case_time_act_action_id_nn not null constraint wf_case_time_act_action_id_fk references workflow_actions(action_id) on delete cascade, -- the timestamp when this action fires fire_timestamp timestamp constraint wf_case_time_act_timeout_nn not null, constraint workflow_case_timed_actions_pk primary key (case_id, action_id) );
After executing an action, workflow::case::action::execute
will:
worklfow_case_timed_actions
which are no longer enabled.
workflow_case_timed_actions
, with
fire_timestamp = current_timestamp + workflow_actions.timeout_seconds
.
The sweeper will find rows in
workflow_case_timed_actions
with fire_timetsamp <
current_timestamp
, order by fire_timstamp, and execute them.
It should do a query to find the action to fire first, then release the db-handle and execute it. Then do a fresh query to find the next, etc. That way we will handle the situation correctly where the first action firing causes the second action to no longer be enabled.
Every time the sweeper runs, at least one DB query will be made, even if there are no timed actions to be executed.
Possible optimizations:
Use cases:
IS THIS DIFFERENT FROM THE TRIGGER/EVENT/WHATNOT STUFF ABOVE?
Some process is triggered by typically a timer on an action being enabled.
Use cases: