Call Procedure
Das Modul "Call procedure" führt eine Stored Procedure (bzw. unter Exasol ein Script) in einer Datenbank aus. Der Aufruftext steht in der Transformation. Das Modul kann den Aufruf einmal ausführen oder für jede Zeile einer optionalen Loop Query wiederholen.
| Name | Bedeutung |
|---|---|
| Modul | Call procedure |
| Modulklasse | DsModExecProcedure |
| Typ | Java |
| Zweck | Datenbankprozedur ausführen |
| Transformationscode | Prozeduraufruf (ohne führendes CALL / EXECUTE SCRIPT) |
| Quellen | Optionale Tabellen in einer Datenbank (zur Auswahl der Connection) |
| Ziele | Optionale Tabellen in derselben Datenbank |
Beschreibung
Im Action Body steht der Prozeduraufruf inklusive Argumente, zum Beispiel my_schema.refresh_stats() oder load_partition('${target_table}'). Das Modul setzt diesen Text in den Dialekt der Zieldatenbank:
- die meisten Datenbanken:
CALL <action>bzw. JDBC-Escape{call <action>} - Exasol:
EXECUTE SCRIPT <action>
CALL oder EXECUTE SCRIPT gehören nicht in den Action Body. Freemarker-Platzhalter im Action Body werden einmal vor der Ausführung ersetzt, mit den üblichen datasqill-Variablen (Batch, Action, Sources, Targets, Modul-Zeitstempel usw.).
Die Datenbankverbindung wird in dieser Reihenfolge gewählt:
- alle Quelltabellen (Objekttyp Tabelle), die dieselbe Connection haben
- sonst alle Zieltabellen, die dieselbe Connection haben
- sonst das Attribut Source Database
Verweisen Quellen oder Ziele auf mehr als eine Datenbank, fällt das Modul auf Source Database zurück.
Beim Validate prüft das Modul, ob der Prozeduraufruf vorbereitet werden kann, setzt Objektrechte für Quellen und Ziele und vermerkt eine unbekannte Abhängigkeit zur gewählten Datenbank. Beim Run wird der Aufruf ausgeführt und committed.
Loop Query
Ist Loop Query gesetzt, wird die Prozedur einmal pro Ergebniszeile ausgeführt. Jede Iteration wird einzeln committed. Die Loop Query wird auf derselben Connection als SQL validiert. Schema-Namen in der Loop Query werden über das Schema-Mapping der Connection umgeschrieben.
Der Action Body wird nicht pro Loop-Zeile erneut getemplatet, und die Spalten der Loop Query werden keine Freemarker-Variablen. Die Loop wiederholt nur denselben Aufruf. Das ist sinnvoll, wenn die Prozedur selbst das nächste Arbeitspaket wählt oder wenn derselbe Aufruf N-mal mit Commit dazwischen laufen soll.
Liefert die Loop Query keine Zeilen und ist Error if Loop empty aktiv, bricht die Transformation mit Fehlercode -119 ab.
Datenquellen
Quellen sind optional. Wenn es Tabellen sind, sollen sie alle zu der Datenbank gehören, in der die Prozedur läuft. Der datasqill-Laufzeitbenutzer braucht Execute-Rechte auf der Prozedur und die Rechte, die die Prozedur selbst benötigt.
Datenziele
Ziele sind optional. Sie dienen wie die Quellen der Connection-Auswahl und der Rechteprüfung beim Validate. Die Prozedur darf in diese Tabellen schreiben; das Modul erzeugt selbst kein DML.
Attribute
| Name | Typ | Bedeutung |
|---|---|---|
| Source Database | Connection | Connection, wenn Quellen und Ziele keine eindeutige Datenbank ergeben (Default: Connection 1). |
| Loop Query | SQL | Optionale Query. Die Prozedur wird einmal pro Ergebniszeile aufgerufen. |
| Error if Loop empty | Boolean | Wenn aktiv und die Loop Query keine Zeilen liefert, schlägt die Transformation fehl (Default: N). |
Trigger
Das Modul bietet folgende Connection-Trigger:
- After Database Open
- Before Validate / After Validate
- Before Loop / After Loop
- Before Iteration / After Iteration
- Before Commit / After Commit
Mit Loop Query umschließen Before Loop / After Loop den gesamten Cursor, Before Iteration / After Iteration sowie Before Commit / After Commit laufen je Zeile. Ohne Loop Query läuft der Aufruf einmal (Before/After Iteration, danach Commit).
Statistiken
Das Modul liefert unter anderem:
| Name | Bedeutung |
|---|---|
| write_duration | Zeit für die Prozeduraufrufe, in Nanosekunden |
| convert_duration | Zeit außerhalb des Aufrufs (Templating, Open, Close), in Nanosekunden |
| module_duration | Gesamtlaufzeit des Moduls, in Nanosekunden |
| iterations | Anzahl der Prozedurausführungen |
rows_processed kommt vom JDBC-Update-Count des letzten Aufrufs (0, wenn der Treiber keinen liefert).
Beispiele
Einzelner Prozeduraufruf
Action Body:
staging.refresh_aggregates()
Die Tabellen, die die Prozedur liest oder schreibt, sollten verbunden sein, damit datasqill die Connection wählen und Abhängigkeiten anzeigen kann.
Aufruf mit Freemarker
Action Body:
staging.load_partition('${target_table}')
${target_table} kommt vom einzelnen Tabellenziel der Transformation.
Denselben Aufruf wiederholen
Loop Query:
SELECT 1 FROM staging.work_queue WHERE status = 'READY'
Action Body:
staging.process_next_item()
Die Prozedur läuft einmal pro Queue-Zeile. Jeder Lauf wird committed. Error if Loop empty einschalten, wenn eine leere Queue die Transformation fehlschlagen soll.