...
- Core tables (Task, TaskProcess, Dataset, TPInstance, and DSInstance) may satisfy requirements with minor modifications
- Some of Dan's original, simple, constraints (and tables such as TP_DS) may be too restrictive to allow things such as parallel processing.
To be replaced with something in the nature of a list of conditions for further processing. - Upon Karen's suggestion, enumerated tables to have their integer Primary Keys removed, replaced with enumerated value as Primary Key.
Significantly reduces amount of SQL code devoted to joins.
Still provides UI the advantage of an enumerated list of possible values.
Karen warns that this requires more work to change (or remove) an enumerated value.Info title Dan claims ...This this drawback is rare and easily significantly offset by the time-cost benefit in coding, and readability/maintenance of code.
- Some of Dan's original, simple, constraints (and tables such as TP_DS) may be too restrictive to allow things such as parallel processing.
- Changes to naming of tables and quantities should be considered due to the proliferation of the word 'Task' as seen in the next section.
...
- Allows for subTasks within Tasks, ie: logical groupings of TaskProcesses into a subTask
- Such a subTask could conditionally depend on status of 'sibling' TaskProcesses within it's its Parent Task
- And TaskProcesses within parent Task could depend on the 'sibling' child Task or upon the TaskProcesses contained within said child Task
- Every Task (including subTasks) can have many implementations (formerly called runs)
- Every TaskProcess can have many instances per implementation of it's its parent Task (formerly called TPInstances, of which only one instance could occur per implementation of it's its parent Task)
- A TaskProcess (or subTask) can depend on the conditional completion of one or all of another TaskProcess or subTask instances.
- Igor presents the notion that parallel TPInstances may want to inter-communicate. Judement Judgment is reserved on the issue.
...