[Allegro] UPDATE aendert zu viele Schluessel?

[Thomas Berger]

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

Lieber Herr Eversberg,

ausgehend vom Beispiel "Kategorienergaenzung" von heute nachmittag,
habe ich das Kategorien-Ergaenzen ueber einen Globale-Manipulation und
zugeschaltete Parameterdatei beim UPDATE geloest, d.h. aus dem
"Neuer Datensatz" wird die fragliche Kategorie eingesammelt, dann
mit M dort geloescht, dann aus dem "vorhandenen Datensatz" die
fraglichen Kategorien zu Vergleichszwecken eingesammelt und schliesslich
im Abschnitt fuer globale Manipulation jeweils verglichen, ob die
neue Kategorie evtl. bereits vorhanden ist, wenn nicht, wird sie mit
M-Befehl angehaengt.

Dabei fiel mir auf:

1.) bei "vorhandener Datensatz" lasse ich fuers Protokoll mittels ##
den Satz auswerfen: Hier wird #00 nicht gezeigt (liegt das an der
vorausgegangenen Kategorieloeschung im "neuen Datensatz"?)

2.) Durch den zusaetzlichen Vergleich im GM-Abschnitt wird die
Angelegenheit idempotent, d.h. wenn ich die Aktion mit denselben
Eingangsdaten noch einmal laufen lasse, aendert sich nur noch der
Datumsstempel. Der wird in der fraglichen Datenbank nur tagesgenau
indexiert, daher war meine Ueberraschung gross, als Update dennoch
zwischen 13 und 30 geaenderten Schluessel pro Datensatz mitteilte.

Diese Zahl ist deutlich kleiner als die Anzahl der Schluessel, die
der jeweilige Satz produziert, aber doch deutlich groesser als die
"0 Schluessel", die tatsaechlich geandert werden sollen / geandert
werden.

Ich kann beobachten, dass sich der Datumsstempel der .adx nicht aendert
(die Groesse auch nicht), d.h. immerhin werden nicht ueberfluessigerweise
Schluessel ausgetragen und dann identisch wieder eingetragen.
Nicht beurteilen kann ich, ob hier versucht wird, Schluessel einzutragen,
und erst ganz spaet bemerkt wird, dass die benoetigte Satznummer unter
dem errechneten Schluessel bereits nachgewiesen ist. Beim Indexieren
der Saetze erfolgt eine Vielzahl von v14-Ersetzungen und damit
Indexzugriffe, schwer zu sagen, ob hier noch x Schluessel ueberfluessig
lokalisiert werden. Subjektiv scheint mir das Update fuer ein NOOP
etwas langsam, /deutlich/ merkbar waeren aber nur Umspeicherungen in
den .ald-Dateien oder Umlagerungen in den Indexstrukturen ("Wachstum"
des Index).
Weitere Vergleiche sind ansonsten muehsam, auch bei -R3 werden z.B.
nicht alle Konsolmeldungen in die Logdatei geschrieben, die ueber die
Anzahl der veraenderten Schluessel z.B. nicht, d.h. ich kann nicht so
recht vergleichen, ob die Anzahl der veraenderten Schluessel beim
ersten Durchlauf, wo ja tatsaechlich eine Kategorie ergaenzt wurde,
identisch ist.

Vor allem aber bin ich unsicher, ob hier nicht etwas schief laeuft
und nur zufaellig kein Schaden entsteht oder sichtbar wird, schliesslich
gibt es ja noch offene Irritationen im Kontext von UPDATE und
Globaler Manipulation, vgl.

http://sun250.biblio.etc.tu-bs.de/pipermail/allegro/2009-July/029789.html
(Original
http://sun250.biblio.etc.tu-bs.de/pipermail/allegro/2009-April/029434.html )

und

http://sun250.biblio.etc.tu-bs.de/pipermail/allegro/2009-June/029667.html
(plus folgende im Thread)

acon ist derzeit immer noch nicht stabil genug, um eine Alternative zu
sein, vgl. den Kracher

http://bugzilla.gymel.com/show_bug.cgi?id=518

und Verbesserungsvorschlaege
http://bugzilla.gymel.com/show_bug.cgi?id=517
http://bugzilla.gymel.com/show_bug.cgi?id=516


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

iQCVAwUBSnIWmGITJZieluOzAQLFPAP/XAW1g5kp0/q+ZI6tKUQcooxU6CEo0JND
qZebnSxaS9qatgiFiYDe/XLeDhQBypOwfJFasqn051Ao8cAd/OXk2w4oTl/zugXw
eul7dCjms7XZ1oPuYYninyEjPBp9SZI+7kCqYfuXuItn3cgNAJlNr90zny5/9Zq1
wAVUXRKCxYg=
=pUxd
-----END PGP SIGNATURE-----