Tabelle in Event updaten

[DSP]

Tach Zãmma,

habe gerade ein Problem, das ich hier nicht recht einzuordnen weiß, sage daher einfach mal, dass es sich um ein Algo/Design Problem handelt. Jetzt mal die Aufgabenbeschreibung:

Wir haben ein Table mit verkürzten Datensatz und Grid. Im Grid selbst soll ein einer Relation nur ein Tupel einen bestimmten Wert erhalten (beispielsweise Radio Button über alle Tupel). Hierzu wird im Grid was passendes realisiert, beim speichern soll dann nachgesehen werden ob ein anderes Tupel der Relation den Wert bereits besitzt und dieser dann ggf zurückgesetzt werden. Hierzu würde ein before-/after Post Ereignis implementiert. Jetzt kommt das Problem, wenn hier eine Rücksendung erfolgt, springt es in der gleichen Tabelle wieder zurück in das Ereignis ohne dass das Ereignis fertig abgearbeitet wird. Kurzum, die Komponente ist nicht rekursiv fähig!

Hat jemand schon mal so etwas realisiert und hat hier einen Tipp, wie man das abbilden kann?

Vielen Dank
dsp

[Perlsau]

Ich verstehe leider nur Bahnhof ... :cry:

[DSP]

Ist eigentlich ganz einfach :)

Man nehme eine TTable -> T

Implementiere ein Event: AfterPost

Dann wird der Tupel (Datensatz, d) {key: 1, Wert: false} auf {1; true} geändert. Der d{2; true} verletzt die Restriktionen und ist daher auf {2; false} anzupassen. Daher irdischen sich im Post gemerkt, ist der aktuelle Datensatz angepasst worden, dann gehe durch die anderen Datensätze und passe die ebenfalls an. Das geschieht im AfterPost von T. Beim Post von T{2; false} wird dann wieder T>AfterPost aufgerufen.... Und die Komponente bekommt einen Knoten :(

Vielleicht ist das Problem nun etwas klarer.

Grüße
dsp

[Captnemo]

Alter...das muss ich 3-4 mal lesen, damit ich es auch nur 1 mal evtl. verstehe.

Zitat:

Zitat von DSP (Beitrag 1303059)

Daher irdischen sich im Post gemerkt, ist der aktuelle Datensatz angepasst worden, ...

Ab dem Satz war ich nämlich raus.


Nimm doch mal was nachvollziehbares, und vielleicht ein wenig Codeschnipsel.

[mkinzler]

Dann hinterlege die Restriktionen (Constraints) im DBMS. Oder verwende BeforePost, dann kannst Du diese noch anpassen oder den zumindest den Post verhindern.

[Perlsau]

Also ich glaube jetzt soweit verstanden zu haben, daß im AfterPost ständig wieder AfterPost ausgelöst wird, was eine Endlosschleife wäre ("die Komponente bekommt einen Knoten").

[TheFrog]

Ich musste die Angabe auch ein paarmal lesen.

Warum setzt Du in der AfterPost()-Methode kein Semaphore, welches Dir anzeigt, dass Du dich gerade in der Bearbeitung der Daten befindest und welches verhindert, dass AfterPost() ein zweitesmal durchlaufen wird? Wenn Du das nicht machst, dann wird AfterPost() natürlich immer wieder aufgerufen.

Nachdem Du die Daten bearbeitet/manipuliert hast, wird das Semaphore einfach wieder zurückgesetzt und die Methode wieder "scharf" gesetzt für das nächste Event.

[Perlsau]

Semaphore? Du meinst ein Flag, also eine globale Boolean-Variable?

[TheFrog]

Ja, sowas wie ein Flag meinte ich.

Die Variable könnte dann innerhalb der Klasse definiert sein (und kann dort natürlich auch private sein). Global hört sich so schlimm an :wink:!

[Perlsau]

Wußtest du schon? Variablen können sogar global und privat sein: Im Private-Abschnitt deklariert, aber für die ganze Klasse global gültig. Und das was du meintest, ist nicht nur sowas wie ein Flag, es ist ein Flag, benutze ich ständig ... echt jetzt :-D

Ein Semaphor ist dagegen was ganz anderes:

Ein Semaphor (von altgriechisch σῆμα sēma „Zeichen“ und φέρειν pherein „tragen“ - also etwa „Signalgeber“) ist eine Datenstruktur, die aus einer Ganzzahl und den Nutzungsoperationen „Reservieren/Probieren“ und „Freigeben“ besteht. Sie eignet sich insbesondere zur Verwaltung beschränkter (zählbarer) Ressourcen, auf die mehrere Prozesse oder Threads zugreifen sollen, wie etwa Erzeuger und Verbraucher, sowie zur Koordination asynchroner Abläufe. Im Gegensatz zu einem Lock bzw. einem Mutex brauchen die Aktivitätsträger, die „reservieren“ und „freigeben“, nicht identisch zu sein.

[TheFrog]

Naja, wenn ich so einen Ablauf im AfterPost implementieren möchte, dann muss ich es irgendwie steuern.

Mir fällt aber gerade ein, warum der Aufruf rekursiv wurde:
Wenn ich im AfterPost einer Table über die gleiche Table-Instanz gehe und weiter Posts anstoße, dann lande ich natürlich wieder im AfterPost() der Table. Wenn ich jedoch in AfterPost() einfach über eine weitere Instanz einer Table (oder einer sonstwie geeigneten Komponenten), welche ich lokal bilde, die Änderungen anstoße, dann lande ich nicht wieder in AfterPost().

Wäre ein Erklärung, wie es überhaupt zu dem Problem gekommen ist, oder?

[TheFrog]

Ich nehme das mit dem Semaphore zurück :-D

[Perlsau]

Muß du nicht. Die Idee war ja in Ordnung, nur der Begriff paßte nicht wirklich. Jemand, der es nicht kennt, Flags zu verwenden, käme durch den Begriff Semaphore niemals auf den Gedanken, daß du damit einfach eine Boolean-Variable meinst, nicht mal nach dem Lesen des verlinkten Wikipedia-Artikels.

[DSP]

Schon mal vielen Dank für die zahlreichen Antworten.

Nr. 1: Trigger
Geht leider nicht, da ich die Daten direkt als Eingabehilfe vorhalte. Wollte nicht bei jeden Tabwechsel die Relation neu einlesen. Daneben möchte ich unabhängig von der zugrunde liegenden DB die Integrität gewährleisten.

Nr. 2: Separate Tabelle
Funktioniert leider auch nicht, da bei einen Post der Sekundärtabelle direkt in das Event der Primärtabelle gesprungen wird. Hatte dies Problem an einer anderen Stelle und habe dies nun in einen Workaround gelöst (anderes Problem).

Nr. 3: Counter
"Und weiss ich nicht mehr weiter, so setz ich mir 'n Schalter" :)
Muss mal schauen, ob dies zum Ziel führt. Werte ich Morgen mal testen. Aktuell würde mir für den Counter ein Integer einfallen mit folgenden Zuständen
-1: nicht prozessiert
0: im aktuellen Datensatz
1..n:
im BeforePost c++
im AfterPost c--

so, dass nur bei c=0 der Durchlauf stattfindet. Bedenken habe ich aktuell, dass das ganze nicht ordentlich prozessiert wird. daher hoffe ich noch auf einen guten Einfall.

Schon mal vielen Dank
DSP