Transaktion in einer SQL UDF durchführen

[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

[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.

[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.