In order to be able to view the status of really large workflows we need to be able to fetch the data in bite-sized chunks.
In order for paging to be viable, you have to have an append-only data model. Lucky for us, we pretty much do.
1) Remove status_history from workflow_executions report
2) Remove child_workflows from workflow_executions report
3) Add creation timestamp to executions
4) Page response based on creation timestamp
5) Add workflow_execution_history report (which is Paged on timestamp.
6) Add child_workflows report (no need for paging probably)
It will be up to the client to re-assemble these paged responses and associate the ExecutionStatusHistory entries with the appropriate Execution.
We probably want to create a paged_workflow_executions and paged_workflow_execution_status_history_entries reports rather than modifying the existing workflow_executions report behavior.
In order to be able to view the status of really large workflows we need to be able to fetch the data in bite-sized chunks.
In order for paging to be viable, you have to have an append-only data model. Lucky for us, we pretty much do.
1) Remove
status_history
fromworkflow_executions
report 2) Removechild_workflows
fromworkflow_executions
report 3) Add creation timestamp to executions 4) Page response based on creation timestamp5) Add
workflow_execution_history
report (which is Paged ontimestamp
. 6) Addchild_workflows
report (no need for paging probably)It will be up to the client to re-assemble these paged responses and associate the ExecutionStatusHistory entries with the appropriate Execution.