[Allegro] neues acon und a99.exe! bei extremsituationen! 4.teil

[Thomas Berger]

Lieber Herr Eversberg, liebe Liste,

da niemand fuer mich in den Index schauen mochte, habe ich nun
die Sache selber testen muessen (mit v35.8)...

> Stellen Sie eine klare Frage statt einer resignierten Konstatierung,
> dann kriegen Sie eine klare Antwort. (Wenn die Frage schon gestellt war,
> haben wir sie wohl in einem Wust von anderen Explikationen übersehen,
> sorry.)

Folgenden Bug gibt es:

il ist definiert als maximale Schluessellaenge *exklusive* den
zwei Zeichen fuer das Praefix |n. Das Handbuch gibt 246 als
maximal waehlbaren Wert fuer il an.

"var p" ist aber automatisch trunkiert auf 246 Zeichen inklusive
Praefix, das entspricht einem il von maximal 244. (in update.job
wird das Ergebnis noch einmal auf 246 Zeichen trunkiert, das
hat keinen Effekt, ausser vielleicht bei aelteren Versionen von
acon)

Konsequenz: Bei il=245 und il=246 *und* Primerschluesseln laenger
als 244 Zeichen funktioniert es nicht: Der im Index stehende /
in den Index gesetzte Schluessel ist effektiv laenger als der,
der von "var p" zum Zugriff angegeben wird.

(Korrektur in acon muss dann eine entsprechende Korrektur in
update.job nachziehen: Das (0,246) ist jetzt uberfluessig,
danach falsch)


Folgende Misslichkeit gibt es:

"var p" reflektiert nicht die aktuelle Setzung von il, d.h.
in der Demo-Datenbank mit il=150 muss man selber darauf achten,
dass der von "var p" gelieferte String maximal 152 Zeichen
hat, denn sonst kann der niemals gefunden werden. Da z.B.
update.job diesen Wert nicht ermitteln kann (und /variable/
Trunkierung mit der Flexsprache extrem muehsam ist), *muesste*
also in den Indexparametern an der Stelle, wo der Primaerschluessel
konstruiert wird, darauf geachtet werden, dass der generierte
Inhalt vor "=" maximal so viele Zeichen hat, wie es il
entspricht (bzw. ein oder zwei weniger fuer il>244).
Andererseits begibt man sich bei Primaerschluesseln, von denen
man selber erkennt, dass sie trunkiert werden muessen, aber
nicht weiss, ob sie trunkiert werden duerfen, in den Bereich
der Probabilistik, will man /zuverlaessige/ Ergebnisse, muss die
Anwendung neu designt werden.

Das geht m.E. in Ordnung, denn bei il=150 kann ja nicht
entschieden werden, ob ein Schluessel mit mehr als 150 Zeichen
gleich oder ungleich dem Schluessel eines anderen Satzes
ist, wenn die ersten 150 Zeichen gleich sind: Dann doch
lieber ein Neusatz!

Insofern waere eine geeignete Korrektur fuer den Bug oben,
nicht die Trunkierung von 246 auf 248 anzuheben, sondern
sogar auf 249 (oder auf il+3): Damit werden Schluessel,
die /wirklich/ laenger sind als il immer noch zuverlaessig
nie gefunden.
[Mag sein, dass das nicht praktikabel ist, weil Suchbegriffe
mit 247 Zeichen (bzw. 249 inklusive Praefix) intern schon
nicht mehr verarbeitbar waeren und daher bei erster Gelegenheit
auf 248 trunkiert werden. Die Frage ist allerdings auch,
warum speziell "var p" vom Programm auf eine feste Laenge
gestutzt wird: Ich erinnere mich, dass es sonst Crashs gab,
die betrafen aber "nur" die Zwischenspeicherung und nicht das
nachfolgende "find" (das ja mit "=?" ohnehin noch zwei Zeichen
ergaenzt). Jedenfalls: Vor jedem "find" manuell dafuer sorgen zu
muessen, dass die einzelnen Terme eine gewisse Laenge nicht
ueberschreiten, waere ausserordentlich laestig.

viele Gruesse
Thomas Berger