[Allegro] V32.4 und Indexparameteraufruf

[Thomas Berger]

Lieber Herr Eversberg, liebe Liste,

> Gleichwohl, und abermals zugegeben, ich sehe nicht, wie alles das
> in überschaubarer Zeit auf die Reihe gebracht werden und dann auch
> noch übersichtlich bleiben könnte.
> Die Forderung, alles das müsse acon reibungsfrei, transparent,
> effizient und fehlerlos bewältigen, ist zur Stunde unerfüllbar.

Wir *wissen*, dass aus konzeptionellen Gruenden gewisse Dinge mit allegro
nicht hundertprozentig funktionieren koennen, naemlich alles was mit
Indexkonsultationen in der Indexparameterdatei zu tun hat, also v14-Ersetzungen
und explizite Nachladungen: Ändert sich eine Information in dem Datensatz,
der Ziel von Verknuepfungen oder Nachladungen ist, muessten *waehrend*
des Speichervorgangs dieses Datensatzes alle diesen nutzenden Datensaetze
umindexiert werden, tendenziell also die ganze Datenbank. Wir haben
aufgrund der maechtigen Moeglichkeiten der Indexparameterdatei in der Regel
aber noch nicht einmal die erforderlichen "Gegenschluessel" um ueberhaupt
zu ermitteln, welche Datensaetze betroffen sein koennten (Es handelt sich
ja um eine beliebige Aenderung im Normsatz, die gerade gespeichert wird und
evtl. ueberhaupt nicht indexierungsrelevant ist). allegro behilft sich
mit der Konstruktion "Pseudoschluessel", dabei definiert der Normsatz im
Prinzip, was seine "Ansetzung(en)" sein koennten, also ~wichtige~
Einstiegspunkte in den Registern, die pauschal (und mehr oder weniger
zutreffend) Aenderungen nachvollziehen sollen. Normalerweise klappt das
zufriedenstellend, fuer gewisse Operationen (etwa nachtraegliche,
ansetzungstechnische Ausdifferenzierung von Normdaten oder Datenbanken,
die einen Mix aus verknuepften und Unverknuepften Inhalten in derselben
Kategorie tragen) geht es grandios schief und eine baldige Reindexierung
ist angeraten.

Ein anderes Problem liegt darin, dass Update seriell Satz fuer Satz
vorgeht, gewisse Datensaetze aber gegenseitige Verweisungen tragen
(allgemein: Der (gerichtete) Graph der Verknuepfungen zwischen den
Saetzen in der Update-Datei hat Zykel und laesst sich daher gar nicht
serialisieren). *In der (welcher)? Datenbank* sind solche Saetze
zwangslaeufig in mehreren Bearbeitungsschritten entstanden (Erzeuge
Satz A. Erzeuge Satz B mit Verknuepfung zu A. Ergaenze Verknuepfung
zu B in Satz A), eine Update-Datei als Momentaufnahme bildet das
normalerweise aber nicht ab. Die Komplettindexierung bekommt das wg.
zwei und mehrstufigem Vorgehen in den Griff, alle aktuellen Update-
Ansaetze hingegen muessen scheitern, vielleicht denkbar waere eine
Routine, die Update und Index -fx1 kombiniert: Erst die gesamte
Update-Datei irgendwie provisorisch in die Datenbank bringen mit
Schluesselberechnung analog index - at 1, dann erst die Mehrheit aller
Schluessel (- at 2) berechnen...

Das sind aber alles Grenzfaelle, mit denen wir seit der Einfuehrung der
entsprechenden Methoden 1994 recht gut leben koennen, ich sehe da
keinen Handlungsbedarf bis 2013.

Aktuell geht es aber "nur" darum, dass das was acon und a99 mit
"get edit" und "set lock" etc. als Sperrsemantik implementieren,
absolut sauber ist und ausserdem hinreichend effizient ablaeuft.
V.a. letzteres sollte ueberhaupt kein Problem sein, weil der
Regelfall ja beleiben soll, dass Saetze ueberhaupt nicht gesperrt
werden, sondern nur beim Schreiben die Datumsstempel-Vergleichsheuristik
angewandt wird.

viele Gruesse
Thomas Berger