Transaktion in einer SQL UDF durchführen

[Fuerchau]

Ein Select ist eine Massenoperation und muss optimiert werden. Deshalb müssen UDF's so einfach wie irgend möglich gestaltet werden.
Du kannst ja nicht verhindern, wo die UDF denn verwendet wird.
Ggf. fällt jemandem ein, dies in der Where-Klausel zu tun und dann kann im Zweifel ein Tablescan passieren statt eines Indexscans.

Schau dir das Transaktionsszenario an:
*CHG liest Daten die Committed sind.
Wenn du also bei einem Select, der 1000de und Millionen von Zeilen liest, eine UDF mit Commit verwendest stellst du den Optimizer vor gewaltige Probleme. Auch andere parallele Zugriffe aus anderen Verbindungen/Jobs werden ggf. Konsistenzprobleme bekommen.

Eine Transaktion in einer DB stellt grundsätzlich kein Problem dar.
Wenn sie denn via Businesslogik vom Client der DB initiiert und kontrolliert wird.
Denn wenn mir irgend eine UDF da dazwischen funkt, kann ich meiner Transaktion nicht mehr sicher sein und auf einen Rollback keinen konsistenten Zustand bekommen.

Ein Commit schreibt geänderte Daten fest!

[dschroeder]

Eine Transaktion in einer DB stellt grundsätzlich kein Problem dar.
Wenn sie denn via Businesslogik vom Client der DB initiiert und kontrolliert wird.
Denn wenn mir irgend eine UDF da dazwischen funkt, kann ich meiner Transaktion nicht mehr sicher sein und auf einen Rollback keinen konsistenten Zustand bekommen.

Ein Commit schreibt geänderte Daten fest!

Langsam wird mit die Problematik mehr und mehr bewusst. In meinem Fall weiß ich natürlich, dass die UDF nur für einen ganz bestimmten Zweck verwendet wird. Aber mir ist dank eurer Erklärungen jetzt klarer, dass man nicht einfach so zwischendurch Transaktionen einstreuen kann.

Ich würde meine Problem am liebsten alle mit RPG lösen. Aber bei Blobs ist RPG ja sehr stark größenbeschränkt. Da erscheint mir SQL als das naheliegende Werkzeug.

[BenderD]

Guten Morgen in die neue Woche!

Ich hätte nicht gedacht, dass eine Transaktion in einer Datenbanksprache wie SQL ein Problem sein würde. Wenn ich das alles lese, glaube ich allerdings, dass ich es in meinem Fall auch ohne Transaktion gehen wird.

Zu dem Thema, ob die UDF nicht eine UPD sein müsste und dass Funktionen nur (einzelne) Daten lesen sollten:

Ich sehe zwischen Funktionen und Procedures keinen gravierenden Unterschied. Eine Funktion hat den Vorteil, dass man zusätzlich zu den Input-Parametern noch einen Rückgabewert bekommt. Das ist hilfreich, weil ich bei Schreiboperationen gerne einen Erfolg oder Misserfolg der Operation zurückbekommen möchte.

Außerdem kann ich Funktione auch im interaktiven SQL einsetzen. Bei UDPs geht das ja nicht bzw. es macht meistens keinen Sinn, da ich ja keine Rückgabewerte bekomme.

... die Transaktionen sein zu lassen, ist nicht die Lösung, sondern ein neues Problem!!! Mit commit *NONE, wie hier häufig empfohlen, hat SQL auf der AS/400 kein zureichendes Sperrkonzept!
Functions sollten grundsätzlich nichts schreiben, wer rechnet in einem select schon damit, dass da geschrieben wird. Eine procedure updateIrgendwas soll schließlich auch nichts löschen!!! In der Denke von SQL wird Erfolg oder Misserfolg durch den SQLCODE bzw. SQLSTATE kommuniziert. Irgendwelche Rückgabevariablen, die Misserfolg signalisieren, sind auch in RPG Murks!!!
Programme via SQL interaktiv aufzurufen sollte man tunlichst bleiben lassen, da werden ganze Scheunentore aufgemacht. SQL ist auch keine taugliche Programmiersprache, das fängt schon bei dem ganzen rudimentären Konzept von Errorhandling an. SQL ist eine Sprache zur Kommunikation mit der Datenbank und sonst nix.

D*B

[dschroeder]

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.

[Andreas_Prouza]

Die problemorientierte Diskussion ist mir hier nicht zielführend.
Am Ende fühlt sich der User überfordert mit all den Problemen und was man alles falsch machen kann und keinem ist geholfen.

Das ist das gleiche wie: Keine Business Logik in SQL. Wir hatten ja schon mal das Thema.
Ich kann ja auch RPG Prozeduren als SQL Funktionen oder SQL Prozeduren verwenden.
Es hängt also nicht von der Sprache oder der Objekt-Art ab, sondern wofür es ist.
Das Design sollte entsprechend dem Einsatzgebiet definiert werden.

Um hier einen lösungsorientiert Vorschlag zu bringen:
Schreib das ganze einfach in einer SQL Prozedur, dann gibt es keine "unabsichtliche Verwendung" in einer WHERE.
Die SQL Prozedur kannst du dann trotzdem in einer SQL Funktion einbauen, wenn es wirklich für den IWS nötig ist.
Sollte diese Funktion dann trotzdem jemand in einer WHERE verwenden, dann habt ihr sowieso ein ganz anderes Problem mit diesem Entwickler ;-)

[Fuerchau]

LOB's kannst du in ILERPG mit SQL ebenso einfach lösen, Birgitta hat das schon öfters propagiert.
Die Frage ist eher, warum deine UDF nicht in RPG lösbar sein soll.

LOB's bis 16MB kannst du mit Hostvariablen im ILERPG simpel lösen, da du einen
varchar(16000000) ccsid(1141) oder einen varucs2(8000000) definieren kannst.
Möchtest du größere Inhalte verarbeiten, geht das mit LOB_LOCATOR, dessen Länge du abfragen kannst und per "exec sql set ..." und substring scheibchenweise verarbeitest.

Größere Dokumente als 8 MB in Unicode sind mir da auch eher selten begegnet.
Handelt sich es um einen einfachen Transfer von IFS-Dokumenten von/zur DB, geht das ebenso mit

dcl-s Filename SQLTYPE(CLOB_FILE);


Insert into .... values(: Filename );
bzw.
Select .... into : Filename ;

Also den Bedarf, dies per SQL machen zu müssen sehe ich da erst mal nicht.

[dschroeder]

Das Problem sind wirklich die Größen. 8 MB für ein LOB ist viel zu wenig. Bei uns können die LOBs Grafikdateien sein (z.B. Firmenlogos) oder andere "PC-Dokumente". Z.B. Excel-Dateien, Fotos oder Videos.
Selbst, wenn ich mit RPG größere LOBs mittels LOB_LOCATOR verarbeiten würde (ich habe das bisher noch nicht gemacht), heißt das doch nur, dass die LOBs irgendwo auf der Platte als IFS-File stehen, oder? Ich müsste sie aber im RPG-Programm als Parameter zurückgeben, damit der IWS sie verschicken kann. Das wird aber nicht gehen, denke ich. Auch den Datentyp SQLRYPE(BLOB) kann man im RPG nicht als Parameter verwenden.

Wenn mir jemand sagt, wie ich LOBs von RPG aus zum IWS bekomme, bin ich da sehr gerne bereit, das auszuprobieren!

[Fuerchau]

Nun, IWS ist ja schon seeeehr alt. Da frage ich mich, ob dies noch zeitgemäß ist.

Aber zurück zur Eingangsfrage:
Was soll denn die UDF schreiben was mit RPGLE nicht geht?
Wie steht das im Zusammenhang mit IWS und dem Aufruf?

Da du die Dokumente > 8MB nicht in RPGLE verarbeiten willst, kann IWS diese doch native mit SQL holen?
Wie gesagt, Dokumente IFS => DB und DB => IFS geht mit oben genannten Methoden.
Wenn ein Dokument nun per IWS an einen Client gesendet werden soll, kann das nicht auch eine Datei aus dem IFS sein die man da vorher hingestellt hat?

Zumal LOB's auch immerhin nur max. 2GB groß sein können, reicht das denn?

Überschreiben von LOB bis 16M in RPGLE:

d ds static
d FileString SQLTYPE(DBCLOB:8000000) ccsid(1200)
d FileData c len(8000000) overlay(FILESTRING_DATA)

[dschroeder]

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]

Hast du meinen Post gelesen?

Schreib das ganze einfach in einer SQL Prozedur

[BenderD]

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]

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.