[Allegro] Mysteriöse Variable

Bernhard Eversberg ev at biblio.tu-bs.de
Do Mai 3 09:57:38 CEST 2012


Am 03.05.2012 09:36, schrieb Thomas Berger:
>
>> Ja. Der Weg scheint mir zu sein, einen neuen set-Befehl zu machen,
>> natürlich nur für acon:
>>
>> set keymode on/off   [default on]
>>
>> wobei dann "off" den Zustand herstellen würde, daß beim Holen eines
>> Satzes die Indexparameter NICHT abgearbeitet werden, aber normalerweise
>> würde das eben geschehen, um automatisch für ein "put" gerüstet zu
>> sein, d.h. dafür kein "set lock" geben zu müssen, mit all den von
>> Berger beschworenen Imponderabilien.
>> Es könnte nunmehr Dissens anheben, ob es nicht andersrum sein sollte...
>
> Ich glaube, da gibt es keinen Dissens: Es gibt einfach keinen Bedarf fuer
> das von Ihnen vorgeschlagene Standardverhalten, es schadet nur (die
> vorbeugende Schluesselberechnung ist Unfug aber selbst die Datensatz-
> sperre ist fuer 99,99% aller Vorgaenge Overkill: In typischen Anwendungen
> werden staendig grosse Ergebnismengen zur Anzeige gebracht, in wenigen
> Anwendungen wird ab und zu ein einzelner Datensatz gespeichert).
>
Sehen Sie, ich dachte es mir doch. Dabei wurde das ganze Hickhack um
die Speicher- und Sperrungen erst durch Sie ausgelöst, nachdem Sie
Probleme an die Wand malten, die noch nie auftraten, und dann diese und 
danach wieder jene Bedenken ausbrüteten, je nachdem, was man vorschlug.
Wer soll da jetzt noch durchblicken!
Aber gut, wir machen es so:

> Es gibt auch keinen Grund, diesen Schalter ueberhaupt einzufuehren:
> Wenn ein Job "get edit" benoetigt, muss er eben "get edit" setzen...
>
Nur, dann muß u.a. update.job auch entsprechend geändert werden UND/ODER
wir müssen mit dem "find" noch was machen, damit es wahlweise beim
Laden des (ersten) gefundenen Satzes auch schon, wie bei "get edit",
die Sperre setzt und die Schlüssel berechnet und dies nicht erst
durch ein nachgeschobenes und u.U. erst Minuten später nach vielen
anderen Änderungen real ausgeführtes "set lock" veranlaßt wird,
worauf dann später beim Speichern zwar nichts kaputtginge aber die
Meldung "jemand anders war schneller" käme.


> In dem Zusammenhang gab es allerdings eine Zusatzdiskussion bezueglich
> "put" bzw. konkreter "put unlock": Hier sollte das Standardverhalten
> m.E. wirklich sein, dass ein Satz hinterher nicht mehr gesperrt
> ist,
Das ist ja so.

> Da acon aber nur einen Datensatz simultan gesperrt halten
> kann,

Es kann nur einen Satz im *Arb.Speicher* halten! Sperren kann es mehrere
und die Sperren auch wieder aufheben. Nur aufpassen muß man dabei.

B.E.



Mehr Informationen über die Mailingliste Allegro