Ereignishandling

[Zvoni]

*seufz*
Die "Rückmeldungen" die du oben erwähnst, sind SQLStates, welche vom Server an den AUFRUFENDEN Client zurückgemeldet werden.
Und diese kann man gewohnt mit Try/Finally/Except abfangen bzw. abfragen, aber eben auch NUR in dem Client, welcher das Statement abgesetzt hat.
Zumindest im Fall von MariaDB/MySQL. Das weiss ich ganz sicher.

Wenn Client A ein fehlerhaftes Statement an den Server absetzt, dann wird auch nur Client A davon informiert "Lern mal gescheit SQL", und eben NICHT zusätzlich Client B, C, und die Putzfrau.

Wenn du willst, dass wenn Änderungen von Client A durchgeführt werden, diese Änderungen dann sofort auf allen anderen Clients sichtbar werden, MUSS Client A eine Nachricht an alle anderen absetzen "Führt mal ein MeinQuery.Refresh aus".
Und zwar aus deinem eigenen Code heraus. Der MariaDB-Server wird das nicht für dich machen.

Und da ist eben der erste Ansatz mit Sockets, wenn man es wirklich so machen will (anstatt in allen Clients einfach nen separaten Thread laufen zu lassen, welcher regelmässig pollt)

EDIT:
Aus deinem Beispiel leite ich ab, dass jeder User auch nen eigenen MariaDB-User bekommt (statt einem "globalen" Application-User, wohl wegen Auditing).
Denk dran: Jedes SQL-Statement wird im Kontext des aufrufenden MariaDB-Users auf dem Server selbst ausgeführt.
Ganz zu schweigen vom Isolation-Level einer Transaction.

Ein INSERT INTO von mir an deinen MariaDB-Server wird im Kontext "Zvoni" ausgeführt, und auch nur an diesen User "zurückgemeldet".
Den Server interessiert es überhaupt nicht, dass noch ein User "wodim" bei ihm angemeldet ist

[wodim]

*seufz*

Ganz meinerseits. Wie lange werden wir wohl noch aneinander vorbei reden?

Die "Rückmeldungen" die du oben erwähnst, sind SQLStates, welche vom Server an den AUFRUFENDEN Client zurückgemeldet werden.
Und diese kann man gewohnt mit Try/Finally/Except abfangen bzw. abfragen,

Muss man wohl.

aber eben auch NUR in dem Client, welcher das Statement abgesetzt hat.
Zumindest im Fall von MariaDB/MySQL. Das weiss ich ganz sicher.

Ja mei, ich arbeite auch nicht erst seit gestern mit RDBMS. Aber wer ist denn in der 3-Tier-Architektur der aufrufende "Client"? Doch nicht der User in der "Anwendungsschicht", sondern?

Wenn Client A ein fehlerhaftes Statement an den Server absetzt, dann wird auch nur Client A davon informiert "Lern mal gescheit SQL"

Bist du verrückt? Ich zitiere mal einen Projektleiter:

SQL-Fehler kommen nicht bis zur QS!

Und schon gar nicht bis zum User (der hat das doch nicht gemacht), und nicht in dem Ton. Wie gesagt: Ein so'n grober Schnitzer, und ich kann den Auftrag vergessen. Und nicht nur den.

Wenn du willst, dass wenn Änderungen von Client A durchgeführt werden, diese Änderungen dann sofort auf allen anderen Clients sichtbar werden, MUSS Client A eine Nachricht an alle anderen absetzen "Führt mal ein MeinQuery.Refresh aus".

Das ist nicht Sache des Clients, sondern der "Objektschicht", noch nicht klar?

Und zwar aus deinem eigenen Code heraus. Der MariaDB-Server wird das nicht für dich machen.

Das hatten wir aber jetzt schon öfters.

Und da ist eben der erste Ansatz mit Sockets, wenn man es wirklich so machen will

Wie das zu realisieren ist, dazu werd' ich schon noch einige Fragen haben ...

(anstatt in allen Clients einfach nen separaten Thread laufen zu lassen, welcher regelmässig pollt)

Das Thema ist doch nun längst vom Tisch.

Aus deinem Beispiel leite ich ab, dass jeder User auch nen eigenen MariaDB-User bekommt (statt einem "globalen" Application-User, wohl wegen Auditing).

Nein, das war doch nur "Demo", dass der Server wirklich jeden Fehler zurückmeldet. Und so wie meine lokale Spielstube hier wird der Server garantiert nicht aussehen, den wir dort aufsetzen.

Denk dran: Jedes SQL-Statement wird im Kontext des aufrufenden MariaDB-Users auf dem Server selbst ausgeführt.

Weiß ich doch.

Ganz zu schweigen vom Isolation-Level einer Transaction.

Das ist ein anderes Thema. Selbstverständlich wird das Transaktionsprinzip konsequent durchgesetzt.

Ein INSERT INTO von mir an deinen MariaDB-Server wird im Kontext "Zvoni" ausgeführt, und auch nur an diesen User "zurückgemeldet".

Da bin ich noch am Überlegen: Für jeden User ein Account in der Datenbank oder eben nur für einen "globalen Application-User" ... Und der soll sich auch nicht jedesmal anmelden müssen, sondern mir schwebt da sowas vor wie: Ein Objekt einer Klasse "Datenbankverbindung", dessen "Connected" - Eigenschaft bei der ersten Anmeldung auf "true" gesetzt wird und worüber dann alle Zugriffe laufen. Liege ich da prinzipiell erst mal richtig?

Den Server interessiert es überhaupt nicht, dass noch ein User "wodim" bei ihm angemeldet ist

Das weiß ich auch, seit ich mit RDBMS arbeite! Willst mich ärgern?

[wodim]

Ob man [...] individuell die Nachrichten für jeden Client händelt, [...] ist dann Entscheidung des Programmierers.

Die ist ja nun gefallen.

(Je Client ein eigener Socket, wird dann lustig mit den Ports),

Wozu das?

[jus]

...
Vielen Dank, Stevie, für die "Korrektur"
Ich hatte ja geschrieben, dass ich nicht mit allen gängigen DBMS gearbeitet habe, und bei MySQL weiss ich es eben definitiv, dass es kein Event-System hat.
Bei Postgres weiss ich, dass Postgres "existiert"

Bei z.B. SQLite: Das hat nen "Hook", um Updates, Commits etc. "abzufangen", hab aber noch nicht wirklich eine Möglichkeit gefunden, daraus Kapital zu schlagen

Und dein Link zum Lazarus-Forum für PQEventMonitor bestätigt meine Aussage: Polling

Also fertig gibt vermutlich bei MySQL nicht wirklich was, aber man kann auch bei MySQL sowas mit UDF basteln. Ich habe vor einiger Zeit für eine Anwendung im lokalen Netzwerk eine UDF als DLL in dem MySQL Server eingebunden. Glücklicherweise lief der MySQL auf Windows. Diese DLL sendet einfach ein UDP Broadcast über WINSOCKET, wenn ein INSERT, UPDATE und DELETE Trigger ausgelöst wird. Die Anwendungen holen sich dann die Updates.

[wodim]

Also fertig gibt vermutlich bei MySQL nicht wirklich was, aber man kann auch bei MySQL sowas mit UDF basteln. Ich habe vor einiger Zeit für eine Anwendung im lokalen Netzwerk eine UDF als DLL in dem MySQL Server eingebunden. Glücklicherweise lief der MySQL auf Windows. Diese DLL sendet einfach ein UDP Broadcast über WINSOCKET, wenn ein INSERT, UPDATE und DELETE Trigger ausgelöst wird.

Hm, wie kriegt die das mit, wenn so ein Trigger ausgelöst wird?

[Zvoni]

Also fertig gibt vermutlich bei MySQL nicht wirklich was, aber man kann auch bei MySQL sowas mit UDF basteln. Ich habe vor einiger Zeit für eine Anwendung im lokalen Netzwerk eine UDF als DLL in dem MySQL Server eingebunden. Glücklicherweise lief der MySQL auf Windows. Diese DLL sendet einfach ein UDP Broadcast über WINSOCKET, wenn ein INSERT, UPDATE und DELETE Trigger ausgelöst wird.

Hm, wie kriegt die das mit, wenn so ein Trigger ausgelöst wird?

Die DLL/so „klinkt“ sich in den DB-server und stellt eine Funktion zur Verfügung, welche wie eine „normale“ funktion in SQL aufgerufen wird, jedoch innerhalb der dll/so ausgeführt, und dort kann man dann damit machen was man will.
Vom Prinzip dasselbe wie stevie für Postgres erwähnt hat

[wodim]

Vergiss die Frage. Ich bin nun mal auf MariaDB (auf Linux) und Tree-Tier fixiert. Aus gefestigten Gründen. Und der DB-Server liefert auch ohne weitere Tricks alles zurück, was man wissen will. Also sag' doch bitte mal was dazu:

Da bin ich noch am Überlegen: Für jeden User ein Account in der Datenbank oder eben nur für einen "globalen Application-User" ... Und der soll sich auch nicht jedesmal anmelden müssen, sondern mir schwebt da sowas vor wie: Ein Objekt einer Klasse "Datenbankverbindung",

.. eben in der "Objektschicht",

dessen "Connected" - Eigenschaft bei der ersten Anmeldung auf "true" gesetzt wird und worüber dann alle Zugriffe laufen. Liege ich da prinzipiell erst mal richtig?

[jus]

...
Hm, wie kriegt die das mit, wenn so ein Trigger ausgelöst wird?

Die Anwendung muß nur einfach an einem vorgegebenen UDP Port lauschen, sobald da was reinkommt holt sich die Anwendung die Daten von der MySQL DB.

[Stevie]

...
Und dein Link zum Lazarus-Forum für PQEventMonitor bestätigt meine Aussage: Polling

Es ging mir ja nicht darum, Dich zu korrigieren oder gar widerlegen, sondern lediglich darum anzumerken, dass PostgreSQL ebenfalls über einen Notification Mechanismus verfügt. Zugegeben, SQLdb scheint bei PostgreSQL in der aktuellen Implementierung nur Polling anzubieten, die Datenbank selbst kann aber auch echte Push Notification und andere Adapter (z.B: PostgresDAC) bieten dann auch Events an, an die man sich mit einer eigenen Methode hängen kann - ganz ohne Polling...

[Zvoni]

...
Und dein Link zum Lazarus-Forum für PQEventMonitor bestätigt meine Aussage: Polling

Es ging mir ja nicht darum, Dich zu korrigieren oder gar widerlegen, sondern lediglich darum anzumerken, dass PostgreSQL ebenfalls über einen Notification Mechanismus verfügt. Zugegeben, SQLdb scheint bei PostgreSQL in der aktuellen Implementierung nur Polling anzubieten, die Datenbank selbst kann aber auch echte Push Notification und andere Adapter (z.B: PostgresDAC) bieten dann auch Events an, an die man sich mit einer eigenen Methode hängen kann - ganz ohne Polling...

Alles gut. Hatte ich auch nicht anderst verstanden.

Vergiss die Frage. Ich bin nun mal auf MariaDB (auf Linux) und Tree-Tier fixiert. Aus gefestigten Gründen. Und der DB-Server liefert auch ohne weitere Tricks alles zurück, was man wissen will. Also sag' doch bitte mal was dazu:

Da bin ich noch am Überlegen: Für jeden User ein Account in der Datenbank oder eben nur für einen "globalen Application-User" ... Und der soll sich auch nicht jedesmal anmelden müssen, sondern mir schwebt da sowas vor wie: Ein Objekt einer Klasse "Datenbankverbindung",

.. eben in der "Objektschicht",

dessen "Connected" - Eigenschaft bei der ersten Anmeldung auf "true" gesetzt wird und worüber dann alle Zugriffe laufen. Liege ich da prinzipiell erst mal richtig?

Bin kein Freund des "Application"-Users. Bringt nur unnötige Komplexität mit.
Da es sich um Patienten-Daten handelt, werf ich jetzt noch zusätzlich Würze rein:
Was ist mit den Datenschutz-Vorschriften (Zugriffsrechte)?
Auditing ("Wer hat was wann gemacht")?

Bei einem "Application-User" müsstest du jedesmal den tatsächlichen Usernamen mitliefern.
Bin mir nicht mal sicher, ob du damit durch die Datenschutzprüfung durch kommst.
Alle Änderungen in der DB werden vom App-User vorgenommen.
Und das wird ja bekanntlich im query-log fortgeschrieben.
https://releem.com/blog/mysql-general-query-log

Details of Log Entries
Grasping the specifics of the log entries is key to meaningful analysis. Each log entry generally includes several important fields:

Event Time – The timestamp when the event occurred.
User Host – The user and host that initiated the query.
Thread ID – A unique identifier for the thread that executed the query.
Server ID – The ID of the server where the query was executed.
Command Type – The type of command executed (e.g., Query, Connect, Quit).
Argument – The SQL statement or command executed.

Heisst im Falle eines "Application-Users": Im log wäre immer derselbe User und derselbe Hostname/IP-Adresse (Die des Rechners, wo die Objektschicht lauft) enthalten.
Ob das wirklich Sinn ergibt?

Unabhängig von allem: Der "middle-tier" (Objekt-/Domänen-Schicht): Wo soll der sitzen?
1) Auf jeder Workstation?
2) Auf dem DB-Server?
3) Eigener Rechner irgendwo im LAN?

Für 2) und 3) sind wir wieder bei Sockets (oder eine andere Netzwerk-Kommunikations-Technik --> Synapse, lnet, wasweissich)

Ich würde mir das an deiner Stelle nochmal gründlich überlegen, sich auf den 3-Tier-Ansatz zu versteifen.

Hab nochmals über die Idee von jus nachgedacht: eine dll/so, welche auf/neben dem MariaDB-Server sitzt, eine UDF exportiert, welche auf dem MariaDB-Server registriert wird,
Trigger einrichten, welche diese UDF nutzen, Funktion wird in der DLL ausgeführt, und lässt ne UDP-Breitseite ab.
Gefällt mir, zumal diese DLL bzw. UDF theoretisch sogar in FreePascal geschrieben werden kann

[Zvoni]

btw: Ich bin wodim noch ne Entschuldigung schuldig.
Ich hatte nicht begriffen, dass er bereits beträchtliche Erfahrung mit Programmierung bzw. Datenbanken hat.

Von daher: Asche auf mein Haupt.

[wodim]

Da bin ich noch am Überlegen: Für jeden User ein Account in der Datenbank oder eben nur für einen "globalen Application-User" ... Und der soll sich auch nicht jedesmal anmelden müssen, sondern mir schwebt da sowas vor wie: Ein Objekt einer Klasse "Datenbankverbindung",

.. eben in der "Objektschicht",

dessen "Connected" - Eigenschaft bei der ersten Anmeldung auf "true" gesetzt wird und worüber dann alle Zugriffe laufen. Liege ich da prinzipiell erst mal richtig?

Bin kein Freund des "Application"-Users. Bringt nur unnötige Komplexität mit.

Ok, ich dachte, das würde es eher vereinfachen.

Da es sich um Patienten-Daten handelt, werf ich jetzt noch zusätzlich Würze rein:
Was ist mit den Datenschutz-Vorschriften (Zugriffsrechte)?
Auditing ("Wer hat was wann gemacht")?

Bei einem "Application-User" müsstest du jedesmal den tatsächlichen Usernamen mitliefern.
Bin mir nicht mal sicher, ob du damit durch die Datenschutzprüfung durch kommst.
Alle Änderungen in der DB werden vom App-User vorgenommen.
Und das wird ja bekanntlich im query-log fortgeschrieben.

Ist bekannt.

Ob das wirklich Sinn ergibt?

Nicht wirklich. Es müsste schon nachvollziehbar sein, wer wann was gemacht hat.

Unabhängig von allem: Der "middle-tier" (Objekt-/Domänen-Schicht): Wo soll der sitzen?
1) Auf jeder Workstation?

Das wäre ja wohl Quatsch. Diese Schicht ist schließlich für die Kommunikation aller Clients mit dem DB-Server zuständig.

2) Auf dem DB-Server?

Schlecht möglich.

3) Eigener Rechner irgendwo im LAN?

Bleibt also nur 3). Und zwar ein Server. Und den DB-Server gleich dazu.

Für 2) und 3) sind wir wieder bei Sockets (oder eine andere Netzwerk-Kommunikations-Technik --> Synapse, lnet, wasweissich)

Ja und - das braucht man ja wohl überall, wo Clients auf einen Server zugreifen können sollen.

Ich würde mir das an deiner Stelle nochmal gründlich überlegen, sich auf den 3-Tier-Ansatz zu versteifen.

Was spricht dagegen?

Hab nochmals über die Idee von jus nachgedacht: eine dll/so, welche auf/neben dem MariaDB-Server sitzt, eine UDF exportiert, welche auf dem MariaDB-Server registriert wird,
Trigger einrichten, welche diese UDF nutzen, Funktion wird in der DLL ausgeführt, und lässt ne UDP-Breitseite ab.
Gefällt mir, zumal diese DLL bzw. UDF theoretisch sogar in FreePascal geschrieben werden kann

Gefällt mir auch, aber so eine Library "klinkt" sich ja nicht in den Server "ein", sondern umgekehrt: Der Server muss so eine Funktion aus der Library aufrufen. Und das muss in den Quellcode des Servers eingebaut werden und der neu compiliert - traust du dir das zu? Ich befürchte, der ist in C oder sowas geschrieben.

https://github.com/MariaDB/server

Und wenn, dann kannst du die Funktion doch gleich da einbauen, nee?

[Zvoni]

Gefällt mir auch, aber so eine Library "klinkt" sich ja nicht in den Server "ein", sondern umgekehrt: Der Server muss so eine Funktion aus der Library aufrufen. Und das muss in den Quellcode des Servers eingebaut werden und der neu compiliert - traust du dir das zu? Ich befürchte, der ist in C oder sowas geschrieben.

Fenkdehler!
Der MariaDB-Server muss eben NICHT neu kompiliert werden!
Die einzige Voraussetzung ist, dass der MariaDB so kompiliert ist, dass er "dynamic loading" unterstützt, und meines Wissens sind die "Off the shelf" MariaDB-Server alle so kompiliert.

Diese Library ist eine eigenständige dll/so, und man muss dem MariaDB-Server nur sagen: "Hey, da ist ne DLL/so, welche dir eine UDF anbietet. Hol dir mal den Funktionszeiger von dort"
Diese UDF (und in welcher dll/so sie liegt) werden dann so gespeichert:
https://mariadb.com/kb/en/mysqlfunc-table/
https://mariadb.com/kb/en/create-function-udf/

Heisst: Immer wenn dann ein SQL-Statement wie
"SELECT MeineUDF(Argumente) blablbla" auftaucht, weiss der MariaDB-Server, dass er in mysql.func nachschaut, ob es die Funktion gibt, in welcher dll/so sie liegt, und kann dann DIREKT an die DLL/so übergeben.
Der Code/Berechnung der UDF findet dann direkt in der dll/so statt (so wie man es sonst auch gewohnt ist, eine Funktion zu benutzen, welche woanderst liegt)

und so ein "SELECT MeineUDF(Arg)" kann eben auch in einem Trigger aufgerufen werden.

EDIT:
Wenn ich es richtig verstanden habe, hat jeder MariaDB-Server ein Unterverzeichnis "plugins" oder so, und genau dort muss diese dll/so hin.
Was ich jetzt aus dem Kopf nicht mehr weiss, ist ob man für ne UDP-Breitseite nen Port braucht (welcher dann auf dem Server entsprechend dann für "ausgehende" Nachrichten offen sein muss)

[wodim]

btw: Ich bin wodim noch ne Entschuldigung schuldig.
Ich hatte nicht begriffen, dass er bereits beträchtliche Erfahrung mit Programmierung bzw. Datenbanken hat.

Jo, etwas verstimmt war ich schon, als du mir zum wiederholten Male das kleine Einmaleins erklären wolltest. Dabei hatte ich schon zum Ausdruck gebracht, dass ich nicht ganz unbeleckt bin. Andererseits auch nur dazulernen kann.

Von daher: Asche auf mein Haupt.

Schwamm drüber. Zur Sache: Was wäre nun gegen das Three-Tier-Prinzip zu sagen? Ich finde, das ist die optimale Lösung, höre natürlich auch gerne andere Meinungen:

Hab nochmals über die Idee von jus nachgedacht: eine dll/so, welche auf/neben dem MariaDB-Server sitzt, eine UDF exportiert, welche auf dem MariaDB-Server registriert wird, Trigger einrichten, welche diese UDF nutzen, Funktion wird in der DLL ausgeführt,

So weit gehe ich mit, aber:

und lässt ne UDP-Breitseite ab.

Und das ergäbe wie gesagt ein Feuerwerk von geschätzt >~90% sinnlosen Messages. Nehmen wir an, 100 User sind gerade aktiv. Wie viele von denen würde wohl interessieren, dass bei der Anmeldung gerade die Daten eines neuen Patienten (von ~>10.000 jährlich) erfasst wurden, dass Dr. Nötigenfalls gerade die Daten von Patient Max Mustermann geändert hat ("Operation gelungen, Patient tot, Angehörige benachrichtigt" oder so), und, und, und, ...

Eben auch dafür ist die "Mittelschicht" zuständig, dass nur die benachrichtigt werden, die gerade mit den Daten von Max arbeiten, und auch gleich die Updates kriegen. Alles in allem eben für die Optimierung des Netzwerktraffics, sagen wir mal. Sehe ich das falsch?

[Zvoni]

und lässt ne UDP-Breitseite ab.

Und das ergäbe wie gesagt ein Feuerwerk von geschätzt >~90% sinnlosen Messages. Nehmen wir an, 100 User sind gerade aktiv. Wie viele von denen würde wohl interessieren, dass bei der Anmeldung gerade die Daten eines neuen Patienten (von ~>10.000 jährlich) erfasst wurden, dass Dr. Nötigenfalls gerade die Daten von Patient Max Mustermann geändert hat ("Operation gelungen, Patient tot, Angehörige benachrichtigt" oder so), und, und, und, ...

Eben auch dafür ist die "Mittelschicht" zuständig, dass nur die benachrichtigt werden, die gerade mit den Daten von Max arbeiten, und auch gleich die Updates kriegen. Alles in allem eben für die Optimierung des Netzwerktraffics, sagen wir mal. Sehe ich das falsch?

Denke schon.
Weil in dem Fall, eben damit die Objektschicht dann weiss, dass von 100 Usern, nur die User 12, 56 und 93 zu benachrichtigen sind, müsste diese User quasi in "Echtzeit" immer der Objektschicht mitteilen, woran sie gerade arbeiten (und aben an Updates interessiert sind).
Das impliziert auch, dass jeder User seinen eigenen "Kanal" (=Socket) zur Objektschicht hat, und das hatten wir ja schon oben.

Bei der UDP-Breitseite kannst du ja einen "Payload"-String mitgeben, z.B. als JSON, oder simpler Text, welcher gewissen Regeln folgt.
Der Payload könnte dann wie folgt aussehen:
"UPDATE - Stammdaten - ID=46823"
Alle 100 User erhalten diese Nachricht, welche durch einen Case Of durch muss.
Und nur User 12, 56 und 93 erkennen aber dass die ID=46823 (Max Mustermann) das ist woran sie interessiert sind.

Das ist jetzt nur rudimentär erklärt.
Ich hoffe du hast verstanden was ich meine.

Im Prinzip lauft es darauf hinaus:
Wer "filtert" die Nachricht? Der "Sender" (=Objektschicht) oder "Empfänger" (=Client)
Bist du wie die Post, die nur "Nachrichten" an explizit genannte Adressaten rausschickt?
Oder eher wie die Tagesschau im TV, wo jeder einschalten kann, wann und wie er will, weil es ihn interessiert?