Ereignishandling

[af0815]

Ein Datenbankserver sagt dir nicht ob such was geändert hat. Da gibt es bei den Sytemen die ich kenne nichts. Das ist in der Verantwortung des Programmieres in Multiuserumgebungen damit umzugehen. Dafür gibt es verschiedene Strategien.

Du bist in deiner Applikation, das sie sich die Informationen besorgt und sich die Events für die Forms und Komponenten erstellt. Manche Ereignisse bekommt man vom Betriebssystem, manche kann über zeitgesteuerte Abfragen erstellen. Das fällt unter Grundlagen der Programmierung auf aktuellen Betriebsystemen.

[Zvoni]

Ein Datenbankserver sagt dir nicht ob such was geändert hat. Da gibt es bei den Sytemen die ich kenne nichts. Das ist in der Verantwortung des Programmieres in Multiuserumgebungen damit umzugehen. Dafür gibt es verschiedene Strategien.

Doch. Gibt es. FireBird hat ein Event-System, was per Observer-Pattern implementiert ist (Glaub ich zumindest)
https://wiki.freepascal.org/TFBEventMonitor

Und in SQLite gibts ne Hook-API die man registrieren kann
https://www.sqlite.org/c3ref/update_hook.html

Du bist in deiner Applikation, das sie sich die Informationen besorgt und sich die Events für die Forms und Komponenten erstellt. Manche Ereignisse bekommt man vom Betriebssystem, manche kann über zeitgesteuerte Abfragen erstellen. Das fällt unter Grundlagen der Programmierung auf aktuellen Betriebsystemen.

Lauft am Ende auf nen eigenen Thread hinaus, der periodisch nach neuen "Daten" sucht
(oder einfach nen Timer auf der MainForm hat)

[wodim]

Ein Datenbankserver sagt dir nicht ob such was geändert hat. Da gibt es bei den Sytemen die ich kenne nichts. Das ist in der Verantwortung des Programmieres in Multiuserumgebungen damit umzugehen. Dafür gibt es verschiedene Strategien.

Oh, viele, viele. Aber meine heißt jetzt "MVC":

viewtopic.php?p=148012#p148012

[wodim]

Hier wird OnActivate jedesmal aufgerufen, wenn INNERHALB der Anwendung MainForm den Focus erhält.

Jaaaa, innerhalb der Anwendung. Wem nützt das was?

Kann es sein, dass Dir da vorschwebt, dass dies auch im Zusammenhang mit anderen Anwendungungen passieren soll?

Selbstverständlich, oder kennst du einen User, der nur mit einer Anwendung arbeitet?

[wodim]

Ein Datenbankserver sagt dir nicht ob such was geändert hat. Da gibt es bei den Sytemen die ich kenne nichts. Das ist in der Verantwortung des Programmieres in Multiuserumgebungen damit umzugehen. Dafür gibt es verschiedene Strategien.

Japp, und tiOPF bringt's leider auch nicht. Ich brauche eine Lösung, die auf dem Server läuft, mit der alle User kommunizieren können.

Ist in der Doku von tiOPF ja schön erklärt.
https://tiopf.sourceforge.net/
https://tiopf.sourceforge.net/Doc/Conce ... nOPF.shtml
http://geldenhuys.co.uk/articles/

Zur Multiuser-Thematik finde ich da leider nirgends was. Liegt das nur an meiner Suchmethode? Dann klärt mich bitte mal auf.

Lauft am Ende auf nen eigenen Thread hinaus,

Nein, auf eine komplette Anwendung, wie man sieht.

der periodisch nach neuen "Daten" sucht (oder einfach nen Timer auf der MainForm hat)

Nein, die unter anderem die Datenbankzugriffe verwaltet und, wenn einer was in der Datenbank geändert hat, das sofort jedem anderen User mitteilt. Natürlich nur, wenn es "seine" Daten betrifft. Sonst wär's wohl ein Feuerwerk von zu 90% wertlosen Messages.

Immerhin habe ich inzwischen wenigstens ein funktionierendes Beispiel gefunden, wie man Messages an eine Form senden kann, auf die sie auch reagiert.

https://forum.lazarus.freepascal.org/in ... #msg331289

Erst mal nur innerhalb einer Anwendung, aber schon mal ein Fortschritt, wenn auch nur ein kleiner.

[Zvoni]

OK, mal Butter bei die Fische wie ein Kumpel von mir immer sagt.

Szenario:
Du hast ne Datenbank auf nem Server laufen (MySQL, MS SQL, Oracle, Sockenschublade, was auch immer).
Es gibt "viele" User, die an deren eigenen Rechnern/Workstations arbeiten, und Daten in der DB "ändern"

Du willst jetzt, dass User A sofort darüber informiert wird, wenn User B etwas in der DB geändert hat.

Es gibt meines Wissens nur ein DBMS, welches ein integriertes Event-System hat: Firebird.
MySQL hat es nicht, MS SQL und viele andere auch nicht (glaub ich zumindest. Hab jetzt nicht wirklich mit allen gängigen DB-Systemen gearbeitet).
PUNKT! Das hat nix mit Lazarus oder FreePascal zu tun. Das hat ausschliesslich was mit dem verwendeten DB-Server zu tun.

Ich sehe zwei Möglichkeiten, deine Aufgabe umzusetzen.
1) Der "klassische" Weg: sogenanntes "Polling" --> jede Workstation schaut in einem definierten Zeit-Intervall nach, ob es was neues gibt --> darauf war mein Kommentar mit eigener Thread/Timer gemünzt
2) Du implementierst so etwas wie ein "Chat"-System: Jeder Client meldet sich an einem zentralen "Chat-Server" an (z.b. per Sockets)
Jedesmal wenn User B etwas an der DB ändert, sendet er einen Broadcast an diesen "Chat-Server", welcher wiederum den Broadcast an alle anderen Clients sendet, und z.B. den Client von User A dazu auffordert einen Refresh durchzuführen.
Siehe auch: https://wiki.lazarus.freepascal.org/Sockets
Insbesondere der letzte Abschnitt mit den Events:

OnEndOfLineReceive : this event occurs where a LF character (0x0A) is received from server.

[Stevie]

Es gibt meines Wissens nur ein DBMS, welches ein integriertes Event-System hat: Firebird.
MySQL hat es nicht, MS SQL und viele andere auch nicht (glaub ich zumindest. Hab jetzt nicht wirklich mit allen gängigen DB-Systemen gearbeitet).
PUNKT! Das hat nix mit Lazarus oder FreePascal zu tun. Das hat ausschliesslich was mit dem verwendeten DB-Server zu tun.

Nun, das stimmt so nicht ganz. PostgreSQL hat ebenfalls ein Event-Management auf Basis der beiden PGSQL-Befehle NOTIFY (https://www.postgresql.org/docs/current/sql-notify.html) und LISTEN (https://www.postgresql.org/docs/current/sql-listen.html), in die sich Clients einhängen können.

Etwas FPC-Anschauungsmaterial dazu befindet sich unter den Beispielen zur Unit SQLdb in der Datei pqeventstest.pp. Ein etwas einfacheres Beispiel für Lazarus findet sich im internationalen Forum: https://forum.lazarus.freepascal.org/in ... ic=42040.0

[Zvoni]

Es gibt meines Wissens nur ein DBMS, welches ein integriertes Event-System hat: Firebird.
MySQL hat es nicht, MS SQL und viele andere auch nicht (glaub ich zumindest. Hab jetzt nicht wirklich mit allen gängigen DB-Systemen gearbeitet).
PUNKT! Das hat nix mit Lazarus oder FreePascal zu tun. Das hat ausschliesslich was mit dem verwendeten DB-Server zu tun.

Nun, das stimmt so nicht ganz. PostgreSQL hat ebenfalls ein Event-Management auf Basis der beiden PGSQL-Befehle NOTIFY (https://www.postgresql.org/docs/current/sql-notify.html) und LISTEN (https://www.postgresql.org/docs/current/sql-listen.html), in die sich Clients einhängen können.

Etwas FPC-Anschauungsmaterial dazu befindet sich unter den Beispielen zur Unit SQLdb in der Datei pqeventstest.pp. Ein etwas einfacheres Beispiel für Lazarus findet sich im internationalen Forum: https://forum.lazarus.freepascal.org/in ... ic=42040.0

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

[af0815]

Vor allen wie soll das sinnvoll funktionieren, mit den Events ? Vor allen, wenn eventuell das ganze über mehrere Standorte verteilt ist. Lokal kann ich es mir vorstellen, aber verteilt ? Was passiert dann, wenn sich Server über replikation abgleichen müssen. Für mich sind die Events keine tragfähige Idee.

[Zvoni]

Vor allen wie soll das sinnvoll funktionieren, mit den Events ? Vor allen, wenn eventuell das ganze über mehrere Standorte verteilt ist. Lokal kann ich es mir vorstellen, aber verteilt ? Was passiert dann, wenn sich Server über replikation abgleichen müssen. Für mich sind die Events keine tragfähige Idee.

Doch, das kann schon funktionieren.
Denk nur mal an die ganzen Anzeigetafeln an Bahnhöfen oder Flughäfen.
Oder ich kenne es aus der Produktion in Firmen, welche z.B. einen grossen Monitor über dem Montageplatz haben, wo in "Echtzeit" z.B. die Zahl der produzierten Einheiten angezeigt wird (Stichwort: Tagesziel).
Die Anwendung, welche auf diesen Monitoren läuft, ist nicht das ERP-System, in welchem die Buchungen stattfinden (und dann ein Update/Refresh versenden), sondern "eigenständige" Programme, welche die Datenbank "abfragen", ob es was neues gibt. Ist meistens Browser-basiert.
Habs schon gesehen, dass jeder solcher Monitor nen Raspberry hinten dran geklemmt hat, auf welchem z.B. nur dieser Browser läuft.
Browser in Autostart, Default URL für Browser-Start konfiguriert, Fertig ist der Lack.
Hatte ich sogar auf unserem alten Sprungplatz (Ich bin Fallschirmspringer) so im Einsatz: unser Buchungssystem war ne Desktop-Anwendung mit MySQL im Hintergrund, welche nur an einem Arbeitsplatz lief.
Die ganzen anderen Monitore (4-5 Stück), welche über das Gelände und in diversen Hallen verteilt waren, hatten jeweils nen minisforum hinten dran geklemmt, darauf lief nur Edge mit vorkonfigurierter URL, welche dann per Timer in JavaScript die Anzeige alle 5 Sekunden aktualisiert hat (und ja, wir hatten nen Kestrel-Server laufen, welcher diese Monitore gefüttert hat)

Geschieht in der Regel per "Polling", kann aber auch mit einem Event-System erreicht werden, sofern das DBMS das auch anbietet (Firebird, PostGres)

[af0815]

Vor allen wie soll das sinnvoll funktionieren, mit den Events ? Vor allen, wenn eventuell das ganze über mehrere Standorte verteilt ist. Lokal kann ich es mir vorstellen, aber verteilt ? Was passiert dann, wenn sich Server über replikation abgleichen müssen. Für mich sind die Events keine tragfähige Idee.

Doch, das kann schon funktionieren.
Denk nur mal an die ganzen Anzeigetafeln an Bahnhöfen oder Flughäfen.
Oder ich kenne es aus der Produktion in Firmen, welche z.B. einen grossen Monitor über dem Montageplatz haben, wo in "Echtzeit" z.B. die Zahl der produzierten Einheiten angezeigt wird (Stichwort: Tagesziel).

Was glaubst du, was ich die letzten Jahre programmiert habe

Nicht nur Lazarus, sondern auch mit RedLion Crimson etc. - da wird immer nur gepollt !! Oder über das Simatik Protokoll auf eine SPS zu gegriffen und daraus ein Event gemacht, ist auch nichts anderes als pollen und lokale Events.

[Zvoni]

Was glaubst du, was ich die letzten Jahre programmiert habe

Woher soll ich denn wissen, was du die letzten Jahre gemacht hast?
Ich weiss ja meistens am Nachmittag nicht, was ich Vormittags gemacht habe

Nicht nur Lazarus, sondern auch mit RedLion Crimson etc. - da wird immer nur gepollt !! Oder über das Simatik Protokoll auf eine SPS zu gegriffen und daraus ein Event gemacht, ist auch nichts anderes als pollen und lokale Events.

Korrekt. Wobei ich persönlich das Polling nicht wirklich mag, da es ja doch meistens aus "no-ops" besteht (weil halt eben nix neues in der DB gefunden wurde).
Und ein Event-System (vom DBMS-Server selbst angeboten bzw. selbst implementiert --> siehe "Chat"-System per sockets) hat dann doch einen gewissen Charme, dass Code eben halt nur dann ausgeführt wird, wenn es auch tatsächlich anfällt.
Ob man jetzt ne UDP-Breitseite abfeuert, oder halt doch individuell die Nachrichten für jeden Client händelt (Je Client ein eigener Socket, wird dann lustig mit den Ports), ist dann Entscheidung des Programmierers.

[wodim]

Du hast ne Datenbank auf nem Server laufen (MySQL, MS SQL, Oracle, Sockenschublade, was auch immer).

MariaDB (ich habe meine Gründe).

Es gibt "viele" User, die an deren eigenen Rechnern/Workstations arbeiten, und Daten in der DB "ändern"

So isses.

Du willst jetzt, dass User A sofort darüber informiert wird, wenn User B etwas in der DB geändert hat.

Nicht nur das. Alle User, die gerade mit diesen Daten arbeiten. Und die sollen nicht nur informiert werden, auch gleich die aktualisierten Daten sehen.

Also was für Ideen ihr da so habt ... Habt ihr das Prinzip "n-Tier" vergessen?

3-Tier.png (51.38 KiB) 6843 mal betrachtet

(Quelle: Wikipedia) Ok, die nennen die Schicht, die "alles" macht, "Domänenschicht" - auch gut. Andere nennen sie "Objektschicht" oder "Objektsuppe".

Also: Die Anmeldung erfasst die Daten eines neuen Patienten. Mit dem Klick auf den Button "Neu" erzeugt die Dame in der "Objektschicht" ein neues Objekt der Klasse "Patient". Mit den Eigenschaften Name, Vorname, Geburtsdatum, Adresse, Telefon, Wehwehchen, Krankenversicherung, zu benachrichtigende Angehörige/Freunde, pipapo. Mit dem Klick auf "Ok" werden diese Eigenschaften mit den eingegebenen Daten gefüllt, und eine Methode "Speichern" aufgerufen. Die bastelt einen SQL-String zusammen, etwa: "INSERT INTO patienten (Name, Vorname, Geburtsdatum, Adresse, Telefon, Wehwehchen, Krankenversicherung, Angehörige_Freunde) VALUES ('Max', 'Mustermann', '11.11.1111', ..., ..., );" und sendet ihn an den Datenbankserver zur Ausführung. Feddich.

Wie das bei "SELECT" (also Daten auslesen) oder "UPDATE" (Daten ändern) laufen soll, muss ich doch jetzt nicht mehr erklären? Die Unterschiede: Erst mal wird nachgeguckt, ob in der Objektschicht schon ein Objekt der Klasse "Patient" mit den Eigenschaften Name = 'Mustermann', Vorname = 'Max', Geburtsdatum = '11.11.1111', ... existiert. Wenn ja, wird's verwendet., wenn nicht, ein neues erzeugt. Mit den Daten aus der Datenbank. Die Besonderheit bei Update eben: Die Anwendungschicht kriegt eine Rückmeldung (üblicherweise wohl "Callback" genannt) über die aktualisierten Daten. Aber eben nur die User, die gerade damit arbeiten.

(Löschrechte wollen wir mal nur dem Admin einräumen.) Und der einzige, der da pollen muss, ist ein "Garbage Collector", der immer mal Objekte aus dem Speicher räumt, die keiner mehr braucht.

Ich weiss ja meistens am Nachmittag nicht, was ich Vormittags gemacht habe

Das ist doch nicht schlimm, hast doch alles gespeichert? Stutzig werden muss du erst, wenn du dir Rasiercreme auf die Zahnbürste schmierst oder dein Frühstücksei küsst und deiner Frau den Löffel auf den Kopf haust.

[Zvoni]

Das ist aber genau das, wovon ich (und die anderen) aber reden:
User A legt einen Patienten Max Mustermann an, und feuert das an den MariaDB-Server ab (INSERT INTO).
Nur der Client von User A weiss genau zu diesem Zeitpunkt jetzt, dass es neue Daten gibt.
Und zwar weil MariaDB selbst eben keinen CALLBACK ausführt "neue Daten" erhalten!

Du brauchst jetzt einen Weg, dass User A eine Nachricht an alle anderen User absetzt "Achtung: Max Mustermann ist jetzt in der DB vorhanden"
Und ja, das wäre jetzt ein Job für die "Domänenschicht" aus deinem Schaubild.

Das Schaubild beschreibt aber eigentlich genau das was ich oben beschrieben habe:
Alle Clients "registrieren" sich bei der Domänen-Schicht.
Was denkst du denn, was so ein "Chat"-Server ist? Wobei ich zugebe, dass "Chat"-Server vielleicht ein schlecht gewählter Begriff ist.

Auch mit dem n-Tier-Ansatz kommst du nicht daran vorbei, dass der MariaDB-Server eben NICHT eine Rückmeldung von sich aus gibt. Und zwar egal ob an die User direkt, oder via dem Umweg über Domänenschicht.

Das musst du von Hand von machen, im Fall von MariaDB

[wodim]

Das ist aber genau das, wovon ich (und die anderen) aber reden:
User A legt einen Patienten Max Mustermann an, und feuert das an den MariaDB-Server ab (INSERT INTO).
Nur der Client von User A weiss genau zu diesem Zeitpunkt jetzt, dass es neue Daten gibt.
Und zwar weil MariaDB selbst eben keinen CALLBACK ausführt "neue Daten" erhalten!

Ja mei, dafür ist die "Domänenschicht" doch da. Die macht eben nicht "fire and forget". Und der DB-Server meldet sehr wohl zurück, wenn ihm was nicht passt. Beispiele (hier auf bash-Ebene):

Code: Alles auswählen

query=$(echo "INSERT INTO accounts(name) VALUES 'Mustermann';" | mariadb -u melinauser -pmelinapw melina)
ERROR 2002 (HY000): Can't connect to local server through socket '/run/mysqld/mysqld.sock' (2)

Daraus muss die "Domänenschicht" also eine Message an den User machen: "Schönen Gruß an Ihren DB-Admin, er möchte Ihnen gefälligst Bescheid sagen, wenn er den Server mal 'runterfährt."

Code: Alles auswählen

query=$(echo "INSERT INTO accounts(name) VALUES ('Mustermann';" | mariadb -u melinauser -pmelinpw melina)
ERROR 1045 (28000): Access denied for user 'melinauser'@'localhost' (using password: YES)

Passwort vergessen?

Code: Alles auswählen

query=$(echo "INSERT INTO accounts(name) VALUES ('Mustermann';" | mariadb -u melinauser -pmelinapw melina)
ERROR 1064 (42000) at line 1: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near '' at line 1

Also Klammer zu, sonst zieht's, Kollege Programmierer.

Code: Alles auswählen

hk@Melina:~$ query=$(echo "INSERT INTO accounts(name) VALUES ('Mustermann');" | mariadb -u melinauser -pmelinapw melina)
ERROR 1364 (HY000) at line 1: Field 'guid' doesn't have a default value

Also von wegen "keine Rückmeldung".

(Übrigens: Melina ist keine Frau, aber eine gewisse Liebhaberei von mir schon.)

Du brauchst jetzt einen Weg, dass User A eine Nachricht an alle anderen User absetzt "Achtung: Max Mustermann ist jetzt in der DB vorhanden"

Nö. Max wird sich doch gleich persönlich auf der Station melden. Und da wissen sie schon Bescheid, die Aufnahme ist schon geplant. (Dafür gibt's 'ne Abteilung "Belegmanagement", ohne Flachs. Mit der Chefin dort hatte ich auch mal Kontakt, allerdings hinterher. Mir aber die Frage verkniffen, wozu sie eigentlich da sitzt.) Bei Update sieht's anders aus.

Und ja, das wäre jetzt ein Job für die "Domänenschicht" aus deinem Schaubild.

Korrekt.

Das Schaubild beschreibt aber eigentlich genau das was ich oben beschrieben habe:
Alle Clients "registrieren" sich bei der Domänen-Schicht.
Was denkst du denn, was so ein "Chat"-Server ist?

Woher sollte ich das wissen?

Wobei ich zugebe, dass "Chat"-Server vielleicht ein schlecht gewählter Begriff ist.

Stimmt, von "Chatten" halte ich eh' nichts. Und da bin ich wohl nicht der einzige. Ich wage auch zu bezweifeln, dass so ein "Chat"-Server für diesen Zweck geeignet ist. Klingt mir eher nach Spielerei. Ist mir jedenfalls den Einarbeitungsaufwand nicht wert. Und dann muss ich vielleicht feststellen, dass er mir genauso viel nützt wie MVC oder tiOPT? Danke, kein Bedarf an einem dritten Fehlversuch! Außerdem "chatten" die Leute in dieser Klink schon, aber per E-Mail.

Auch mit dem n-Tier-Ansatz kommst du nicht daran vorbei, dass der MariaDB-Server eben NICHT eine Rückmeldung von sich aus gibt.

Von wegen, s.o. Und wenn nichts zurückkommt, heißt das was? Genau: Er hat's gefressen!

Das musst du von Hand von machen, im Fall von MariaDB

Sicher doch.