View Full Version : Transaktion in einer SQL UDF durchführen
dschroeder
01-07-24, 14:18
Du hast es exakt beschrieben: Mit RPG und embedded SQL kann ich die Daten (max 2 GB) in eine DB schreiben. Aber dann brauche ich wieder SQL, um Daten per Webservice auszuliefern. Beim IWS kann man ein SQL-Statement angeben, um die Daten auszuliefern.
Zum Schreiben das Gleiche, nur umgekehrt:
Der Webservice Client (eine Java-Anwendung) liefert mir ein großes BLOB, z.B. 20 MB groß, also zu groß für RPG. (Um genau zu sein: Ich bekomme nicht direkt ein BLOB, sondern ein Json-Clob, in dem das Blob base64 codiert enthalten ist. Aber das spielt hier keine Rolle, denke ich)
Das große Clob kann ich im RPG nicht empfangen. Also hänge ich an den IWS kein RPG Programm, sondern eine SQL-Funktion, die das als Clob 2GB empfangen kann. Was soll ich jetzt mit dem Clob weiter machen? Auch die SQL Funktion kann das nicht an RPG weitergeben. Ich könnte es natürlich in eine DB schreiben oder ins IFS schreiben und dann ein RPG Programm aufrufen, das das ganze häppchenweise weiterverarbeitet.
Da finde ich es einfacher, es direkt mit SQL in die Tabelle zu schreiben, wo es hingehört. Zu dem Blob gehören dann noch ein paar Metadaten (z.B. mimeType), die in einer anderen Tabelle gespeichert werden müssen. Da die Speicherung des Blobs also 2 Tabellen erfordert, hätte ich eine Transaktion hier ganz hübsch gefunden.
Andreas_Prouza
01-07-24, 14:31
Hast du meinen Post gelesen?
Schreib das ganze einfach in einer SQL Prozedur
Wenn meine Funktion "writeBlob" heißt, würde ich im select schon erwarten, dass sie etwas schreibt. Ich bin natürlich vollkommen deiner Meinung, dass die Benamung der Funktionen und Methoden wichtig ist und klar ausdrücken muss, was eine Funktion tut.
Commitment Control haben wir von 30 Jahre nicht mitbedacht. Das fällt uns jetzt bei einigen Aktionen auf die Füße, aber es lässt nicht mehr mit vertretbarem Aufwand verändern.
Ich verstehe, dass du es kritisch siehst, wenn versucht wird, mit SQL zu programmieren. Aber ich habe ja bereits oben geschrieben, wie meine Anforderung ist. Es geht um große Blobs. Alle anderen Lösungen, die wir durchdacht haben (Webservices ohne IWS, stattdessen nativ in RPG implementieren oder andere Programmiersprachen (Python, Java, nodes.js) dazwischen zu legen), haben auch gewichtige Nachteile. Deshalb erscheint uns SQL sinnvoll.
... es gibt immer einen Weg, neue Programme transaktionssicher zu bauen. Noch wichtiger ist es, Krücken neu zu bauen, die einem den Weg noch weiter verbauen.
Ansosnten bin ich bei Andreas: Daten per Parameter zu empfangen und in die Datenbank zu schreiben ist Alltagsgeschäft für SQL Prozeduren.
D*B
PS: Ob ich allerdings strategisch auf die morsche Bohle IWS setzen würde - was machst Du eigentlich, wenn IBM den schlachtet?
dschroeder
01-07-24, 15:42
Hast du meinen Post gelesen?
Schreib das ganze einfach in einer SQL Prozedur
Ja, Andreas. Das habe ich gelesen. Aber ich sehe es nicht ein. Ich will auch Rückgabewerte senden. Z.B. "Schreiben hat wegen Sperrung nicht geklappt" oder "Blob wurde angelegt. Die neue ID ist xxxx" oder so. Das würde in einer Procedure doch nicht einfacher sein, oder? Eine Funktion hat einen Rückgabewert, den der IWS automatisch rausreicht.
dschroeder
01-07-24, 15:46
...
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
01-07-24, 15:51
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
01-07-24, 16:04
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
01-07-24, 16:24
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
01-07-24, 16:33
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.
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.ä.