a) Tabelle scheduler_history um pid erweitern
Vielleicht muss der Satz etwas später als bisher geschrieben werden, bis der Scheduler die Pid hat.
Als Default würde ich NULL nehmen.
b) Neue Tabelle scheduler_node_history
Anscheinend ist es nicht eine Geschichte der Knoten, sondern der Auftragsschritte. Die Tabelle könnte dann scheduler_order_step_history heißen.
Als Defaults würde ich für alle Spalten NULL nehmen.
Die Tabelle scheduler_order_history muss schon beim Start des Auftrags beschrieben werden. Dazu wird eine neue history_id (jetzt eigentlich eine Laufkennung, order_run_id) erzeugt und im Auftrag vermerkt. Beschreiben der Tabellen scheduler_order_history und scheduler_orders müssen in einer Transaktion zusammenfasst werden.
Die Spalte ordering ist eigentlich die Schrittnummer. Sie wird für jeden erreichten Jobkettenknoten hochgezählt und in der Tabelle scheduler_orders oder scheduler_order_history gehalten. Zu jedem Insert in die Tabelle scheduler_order_step_history kommt also noch ein Update in die Tabelle scheduler_order_history.
Die Spalte next_state geht konstant aus der Jobkette oder dem folgenden Eintrag hervor, sie enthält keine neue Information.
Error_code und error_text sind redundant mit den Spalten in scheduler_history. Sie werden aber nicht in derselben Transaktion geschrieben, für einen sehr kurzen Moment fallen sie also auseinander. Möglicherweise können beide Transaktionen zusammengefasst werden.
Die Spalte end_state (oder end_state_reached) könnte in scheduler_order_history gehalten werden.
Die Tabelle hätte dann diese 6 Spalten:
- Laufkennung
- Schrittnummer
- Zustand
- Task-Kennung
- Startzeit
- Endezeit
Man könnte Order.state_text dazunehmen.
Der Platzbedarf fällt im Vergleich mit der Speicherung des Auftragsprotokolls vielleicht nicht so ins Gewicht.
Die Geschwindigkeit wird sich verringern, fast so langsam wie verteilte Aufträge.
Man könnte noch überlegen, wie man die Schritthistorie mit den verteilten Aufträgen effizient zusammenbekommt.
Improvement
Reopened
Minor
Closed
a) Tabelle scheduler_history um pid erweitern
Vielleicht muss der Satz etwas später als bisher geschrieben werden, bis der Scheduler die Pid hat.
Als Default würde ich NULL nehmen.
b) Neue Tabelle scheduler_node_history
Anscheinend ist es nicht eine Geschichte der Knoten, sondern der Auftragsschritte. Die Tabelle könnte dann scheduler_order_step_history heißen.
Als Defaults würde ich für alle Spalten NULL nehmen.
Die Tabelle scheduler_order_history muss schon beim Start des Auftrags beschrieben werden. Dazu wird eine neue history_id (jetzt eigentlich eine Laufkennung, order_run_id) erzeugt und im Auftrag vermerkt. Beschreiben der Tabellen scheduler_order_history und scheduler_orders müssen in einer Transaktion zusammenfasst werden.
Die Spalte ordering ist eigentlich die Schrittnummer. Sie wird für jeden erreichten Jobkettenknoten hochgezählt und in der Tabelle scheduler_orders oder scheduler_order_history gehalten. Zu jedem Insert in die Tabelle scheduler_order_step_history kommt also noch ein Update in die Tabelle scheduler_order_history.
Die Spalte next_state geht konstant aus der Jobkette oder dem folgenden Eintrag hervor, sie enthält keine neue Information.
Error_code und error_text sind redundant mit den Spalten in scheduler_history. Sie werden aber nicht in derselben Transaktion geschrieben, für einen sehr kurzen Moment fallen sie also auseinander. Möglicherweise können beide Transaktionen zusammengefasst werden.
Die Spalte end_state (oder end_state_reached) könnte in scheduler_order_history gehalten werden.
Die Tabelle hätte dann diese 6 Spalten:
Man könnte Order.state_text dazunehmen.
Der Platzbedarf fällt im Vergleich mit der Speicherung des Auftragsprotokolls vielleicht nicht so ins Gewicht.
Die Geschwindigkeit wird sich verringern, fast so langsam wie verteilte Aufträge.
Man könnte noch überlegen, wie man die Schritthistorie mit den verteilten Aufträgen effizient zusammenbekommt.
- Laufkennung
- Schrittnummer
- Zustand
- Task-Kennung
- Startzeit
- Endezeit
Man könnte Order.state_text dazunehmen. Der Platzbedarf fällt im Vergleich mit der Speicherung des Auftragsprotokolls vielleicht nicht so ins Gewicht. Die Geschwindigkeit wird sich verringern, fast so langsam wie verteilte Aufträge. Man könnte noch überlegen, wie man die Schritthistorie mit den verteilten Aufträgen effizient zusammenbekommt.