Present:

  • Flath, Daniel
  • Focke, Warren
  • Heidenreich, Karen
  • Johnson, Tony
  • Pavlin, Igor

Agenda:

  • Existing Database Schema (Pipeline I) and discussion
  • Tony's New XML Schema and discussion

Detailed Agenda:

Existing Database Schema (Pipeline I) and discussion:
  • 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.
      (info) 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.
      (plus) Significantly reduces amount of SQL code devoted to joins.
      (plus) Still provides UI the advantage of an enumerated list of possible values.
      (minus) Karen warns that this requires more work to change (or remove) an enumerated value.
      • (info) Dan claims this drawback is rare and significantly offset by the time-cost benefit in coding, and readability/maintenance of code.
  • Changes to naming of tables and quantities should be considered due to the proliferation of the word 'Task' as seen in the next section.
Tony's New XML Schema and discussion:
  • 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 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 its parent Task (formerly called TPInstances, of which only one instance could occur per implementation of 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. Judgment is reserved on the issue.

Additional Notes:

  • Dan has requested a new Oracle username/tablespace, GLAST_DP_TEST, on GLASTP
  • Dan has created a new CVS package, Pipeline, initially with a subdirectory, DB, containing the most current Pipeline I DB schema and stored procedures definition files
  • No labels