Transaktion in einer SQL UDF durchführen

[dschroeder]

...
PS: Ob ich allerdings strategisch auf die morsche Bohle IWS setzen würde - was machst Du eigentlich, wenn IBM den schlachtet?

Berechtigte Frage.
Zunächst gehe ich davon aus, dass wir das mit etwas Vorlaufzeit mitbekommen werden. Wir hätten dann genug Zeit, eine Schicht (wahrscheinlich in Java) zu bauen (nicht ich, sondern unsere Java-Developer), die das IWS ersetzt. Mit Springboot ist das auch kein Hexenwerk.

Wir hatten auch schon Kontakt mit Andreas (Prouza). Er hatte da Ideen, so eine Schicht auch in Python oder ähnlichen Sprachen zu bauen.

Ich denke, da gibt es mehrere Möglichkeiten.

[Andreas_Prouza]

Hast du auch den nächsten Satz gelesen?

Die SQL Prozedur kannst du dann trotzdem in einer SQL Funktion einbauen, wenn es wirklich für den IWS nötig ist.

Ich bilde mir aber ein, dass du die Zuordnung der Parameter von SQL Prozeduren genauso gut machen kannst, wie beim Result von SQL Funktionen.
Bin mir aber nicht mehr sicher, da (wie du weißt) ich auch kein Freund vom IWS bin und für WebAPIs, Python auf der i verwende um genau alle diese Probleme nicht mehr zu haben.

Falls das mit den Parametern aber nicht so funktioniert, dann wie beschrieben die SQL Funktion als Wrapper.

[dschroeder]

Hast du auch den nächsten Satz gelesen?

...
Falls das mit den Parametern aber nicht so funktioniert, dann wie beschrieben die SQL Funktion als Wrapper.

Genau das finde ich nicht gut. Dann hätte ich eine Funktion und eine Procedure.

Ich bin hier anscheinend nicht der Meinung der meisten Foristen:

Ihr meint, eine Funktion wäre nur zum Lesen und eine Procedure nur zum Schreiben. Der Sinn erschließt sich mir (und meinen Kollegen) nicht. Ich bin auch noch nie bewusst auf so eine Beschreibung gestoßen.

Um ehrlich zu sein, habe ich mich allerdings schon des Öfteren gefragt, wofür Procedures eigentlich gut sind. Es geht doch alles so schön mit Funktionen!

Ich dachte, Procedures sind dafür da, irgendwelche Resultset-Rückgaben zu machen. Das setzen wir bislang nicht ein.

Ansonsten betrachten wir Funktionen und Procedures als ziemlich gleichrangig.

[Andreas_Prouza]

Ich sehe es auch differenzierter als die Meisten.

Klar, eine Funktion die z.B. eine Zahl in ein Datum umwandelt, soll keine Commit-Steuerung benötigen.
Ich sehe aber auch kein Problem wenn eine Funktion für mehr verwendet wird.
Wichtig ist nur, dass es entsprechend Definiert wird.

Eine Funktion deren Name "TRANSFER_DATA_2_IFS" heißt, wird hoffentlich in keiner WHERE Bedingung eingebaut.

Funktionen verwende ich, wenn ich lediglich einen Rückgabewerte erwarte und ich diese in SQL Statements verwenden möchte.
Prozeduren verwende ich, wenn ich über die Parameter mehrere Rückgabewerte benötige.

Wenn es aber aus technischer Sicht im IWS einfacher ist SQL Funktionen zu verwenden, warum soll man sich dann ein Beinbruch machen und komplexe Strukturen erschaffen, damit man am ende des Tages einen Heldentod sterben kann.

Wartbarkeit & Sinnhaftigkeit steht über Religion.

[dschroeder]

Danke, Andreas.

Aber bevor hier irgendwo ein Herzklabaster ausgelöst wird , nochmal zur Klarstellung:

Wir haben viele SQL-Funktionen, aber die meisten lesen in der Tat nur Daten. Da wir im RPG fast nur noch Serviceprogramme schreiben, haben wir viele external Functions, die einfach nur Adapter für SQL-Serviceprogramme sind.

Die wenigen Funktionen, die wirklich Daten verändern, sind im Team in der Regel bekannt und sind so benannt, dass es da keine Zweifel beim Aufruf geben sollte.

[Fuerchau]

Im IWS könntest du ja auch folgendes machen:

select * from final table (insert into .....);

D.h, der Insert wird ausgeführt und anschließend wird das Ergebnis wieder gelesen.
Wenn du nun einen Insert-Before-Trigger startest, kann dieser den BLOB/CLOB auswerten und mit den, rudimentären, JSON-Parse-Funktionen den LOB auswerten, der dir i.Ü. als LOB-LOcator übergeben wird.
Über Erfolg/Nicht-Erfolg kannst du dann Felder des Before-Buffers anpassen bevor sie in den DB geschrieben werden.
Das Ergebnis wird vom Select wieder gelesen, ggf. in JSON überführt und zurückgesendet.

Sowas ähnliches habe ich schon mal für eine Kardek-Lagersteuerung gebaut.
Die Lager-Software hat einfach per JDBC auf die IBM i zugeggriffen und per Before-Trigger habe ich die RPGLE-Aktivitäten druchgeführt und den Status in den Insert-Buffer geschrieben.
Dies klappt auch mit Update o.ä.