[Allegro] Playback prinzipiell nicht zuverlaessig

[Thomas Berger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lieber Herr Eversberg, liebe Liste,

Nachdenken ergibt: Das Playback einer Logdatei ist nicht in allen
Faellen geeignet, eine Datenbank konsistent wiederherzustellen.

Der Grund ist ein Defizit bei den protokollierten Informationen in
der Logdatei: Bei Neusaetzen wird nur die Tatsache "Neusatz" und
die Nummer der Zieldatei vermerkt. Es wird /nicht/ die konkret
vergebene Satznummer vermerkt und auch nicht die Anzahl der Zeichen,
die der Satz nach dem Speichern in der .ald-Datei belegt.

In Abhaengigkeit vom NewMode (und auch der aktuell eingestellten
Fuellzeichenzahl?) wird beim Speichern eines Neusatzes entweder
ein vorgehaltener Loeschdatensatz (aus geeigneter Datei, mit
geeigneter Groesse) herangezogen oder ein "echter" Neusatz mit
Satznummer groesser als alle bislang vorhandenen.

Die Playback-Funktion /muss/ in dieser Situation dieselben Ermittlungen
vornehmen, wie sie beim urspruenglichen Speichervorgang stattgefunden
haben, denn eine spaetere Aenderung ~dieses~ Datensatzes ist in
der Logdatei unter dessen interner Satznummer verbucht, wenn sich
hier die urspruengliche Anwendung fuer "Neue Satznummer" und das
Playback fuer "recyclen" entschieden hat oder umgekehrt, ist diese
spaetere Satznummer nicht vorhanden oder enthaelt einen (geloeschten
oder aus spaeteren Vorkommen aktivierten) anderen Datensatz.

Ob und welche neue bzw. recyclete Satznummer vergeben wird, haengt
zudem auch noch von der Art der Umspeicherung bei vorherigen,
"normalen" Speichervorgaengen in der Log-Datei ab: Nutzt das Playback
hierfuer einen recycleten Satz, wo der Originalvorgang einen
echten Neusatz kreiert hat, wird bei einem spaeteren Neusatz in
der Logdatei dieser recyclete Satz abweichend zum Original nicht
nutzbar sein oder ein echter Neusatz abweichend vom Original eine
niedrigere Satznummer bekommen. Insofern kann bereits eine
Abweichung um ein einziges Fuellzeichen bei einem normalen
Umspeichervorgang Einfluss auf spaetere Umspeichervorgaenge und
letztendlich auf abweichende Satznummern von Neusaetzen haben.

Nach meiner Einschaetzung zieht eine einzige Satznummern-Inkonsistenz
eine ganze Kaskade von weiteren Fehlzuordnungen beim Playback
spaeterer Datensaetze mit sich: Wurde auch nur einmal faelschlich
recyclet bzw. nicht recyclet, haben alle spaeteren Neusaetze garantiert
abweichende Satznummern und jede im weiteren protokollierte Aenderung daran
trifft garantiert einen falschen Datensatz (oder eine nicht existierende
Satznummer).

Die Playback-Funktion /kann/ aber i.A. nie zu denselben Ergebnissen
kommen, wie sie die urspruenglichen Speichervorgaenge gezeitigt haben,
denn NewMode und Fuellzeichenzahl (und mittelbar ist sogar der
Schalter -z fuer die Dateigroesse von Belang) lassen sich durch Aufrufschalter
bzw. Wahl einer geeigneten .CFG-Datei bzw. adhoc-Setzungen in a99
und darunter ausgefuehrten Flexen variabel gestalten, wohingegen eine
Playback-Funktion mangels individueller Information zu den einzelnen
Speichervorgaengen von einer Konstanten Einstellung ausgehen muss.
"Nummerntreue Entlueftungen" von .ald-Dateien aendern den Pool der
recyclebaren Saetze ebenfalls ganz gravierend und haben damit Einfluss
auf die Konsistenz eines spaeteren Playbacks: Die Nummerntreue hilft
da also nichts.

Fazit: Die interne Satznummer muss auch bei Neusaetzen unbedingt
in der Logdatei vermerkt werden, dann gibt es wenigstens keine
Inkonsistenzen. (Wg. NewMode, -z und Fuellzeichenzahl wird das Ergebnis
eines Playback-Vorgangs dann immer noch nicht bytegenau identisch
sein, aber funktional identisch. Auch die Nummer der .cLD-Datei
ist m.E. zwar "nice to have" aber durchaus verzichtbar).

Das Format der Logdatei muss sich also dringendst aendern, es koennte
veraendert werden, indem auch Neusaetze die Satznummer am ueblichen
Ort tragen und  alle Saetze die (verzichtbare) Zusatzinformation in
(etwa als Pseudokategorie(n) ausgestalteten weiteren Feldern.
Oder aber es koennte "kompatibel erweitert" werden, indem Neusaetze
weiterhin die Dateinummer an der Position der Satznummer transportieren
und die Zusatzfelder die essentielle Satznummer etc.

viele Gruesse
Thomas Berger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iJwEAQECAAYFAk3iVNMACgkQYhMlmJ6W47MBFgQAtSWRkW6tkdfUtko9mLV3qyiY
4g1V9lc9jJI6og/IH2R+BLnKaeJxJLRvQ0tNuY13e9v6ZMZ89EOZRq2jP+SwX3fI
WaHLfGTJHVNCbfpCvJYatrfhcQKZPXavr0GeQ8Rk0ID9wFj5caEjeyCqsNPSMmpv
K5W4kjoSCrD6I1Al8/s=
=z+5k
-----END PGP SIGNATURE-----