[Allegro] Desiderate zu Logdatei und Aehnlichem

[Thomas Berger]

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

Lieber Herr Eversberg,

|> kann dann manchmal helfen. Koennten die allegro-Module nicht beim
|> Loeschen einen regulaeren Datumsstempel mit Bearbeiterstempel setzen?
|> (Dann koennte das auch in die a99-Vergleichs-Heuristik: Von einem Satz,
|> den waehrend ich draufstarrte jemand anders bearbeitet hat, will mein
|> Kollege evtl. nicht, dass ich ihn zum Schluss loesche?)
|>
| Also vor dem Löschen erst nochmal mit frischem Stempel speichern?
| Oder diesen nur in die LOG-Datei?

letzteres, auf das eventuelle Umspeichern bei einer Loeschung wuerde
ich gerne verzichten ;-).


|> Kleinere Desiderate:
|> Ein Extra-Schalter, der - sofern gesetzt, Default sollte "aus" sein -
|> bei Aenderungen an Datensaetzen zwei Eintraege in die Log-Datei
|> setzt: Zunaechst den Stand des Satzes vor der Aenderung (mit geeignet
|> zu definierender Kennung) und dann wie gehabt den geaenderten Satz:
|> Dann kann man gerade bei Saetzen, die eigentlich gar nicht haetten
|> angefasst werden sollen und Jahrelang auch nicht angefasst wurden,
|> anhand der Logdatei besser rekonstruieren, was da eigentlich los war,
|> bzw. ob der Satz durch die Bearbeitung kaputtgegangen ist oder es schon
|> vorher war.
| Dann müßte aber eine Kennzeichnung hinzukommen, die beim Restaurieren
| mit  UPDATE -f9  verhindert, daß solche Originalsätze dann nochmals
| eingemischt werden.

Klar, und auch log2alg sollte diese Sorte Saetze moeglichst bemerken.


|> Neusaetze vermerken ja nicht ihre Satznummer in der .LOG-Datei,
|> sondern nur "neu" plus Nummer der .cLD-Datei, in der sie
|> gespeichert wurden. Vermutlich aus diesem Grund hat das "regulaere"
|> Update das Verhalten, dass Neusaetze (#u1 #####nnn) stets als
|> Neusatz verarbeitet werden. Oft jedoch wuenscht man sich ein
|> Verhalten "wenn der Satz ein Neuer Satz ist, dann packe ihn in
|> Datei nnn, ansonsten ersetze ihn". Koennte man dafuer nicht einen
|> Spezialwert (etwa #u1 ?????nnn) implementieren?
|>
| Dies würde ja nur dann wichtig, wenn man die LOG-Datei NICHT mit der
| normalen Restaurierung (UPDATE -f9 ...) einspeist, sondern vorher mit
| log2alg umwandelt und dann mit UPDATE -fm... einspeist. Das könnte dann,

Diese Methode wuerde ich fast schon als Regelfall bezeichnen. Der
"Klassiker": Datenbank kaputt, Logdatei ganz und fehlerfrei, ist
ja eher utopisch.


| weil man dabei sowieso ganz gut wissen muß, was man tut und erreichen
| will, auch so geschehen, daß man einen anderen Primärschlüssel
| einstellt.

Wie das? Damit kann ich hoechstens erzwingen, dass auch Saetze ohne
#u1 ####  als Neusatz in der Standarddatei landen, also genau das
Gegenteil von dem, was mir vorschwebte.

Abgesehen vom von mir nur als thematische Klammer gewaehlten Beispiel
einer Logdatei wird das gewuenschte Verhalten immer dann wichtig, wenn
man (Fremd-)Daten aus einer Datei mit Update einspielen will, z.B.
solche mit einem Mix aus Titel- und Stammsaetzen, oder weil man fuer die
eigene Datenbank gerne die Saetze getrennt halten will (Lokal- und
Exemplarsaetze, diese und jene Stammsaetze, monographische und
Aufsatzdaten, Hauptaufnahmen und Bandauffuehrungen etc.) Man kann
derzeit die ins allegro-Format umgewandelten Daten zwar mittels x
SRCH-Laeufen in eine Anzahl Grunddateien umwandeln und die dann alle
nacheinander und einzeln mit UPDATE einmischen, das ist aber ein
ziemlicher Aufwand (und moeglicherweise gibt es auch Abhaengigkeiten
in der Reihenfolge, die schwer zu kontrollieren sind).
Besser waere es, wenn Saetze bei der Umwandlung einen "Hint"
eingepflanzt bekommen koennten, wohin sie gespeichert werden sollen,
*falls* es eine Wahl gibt.

viele Gruesse
Thomas Berger

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

iQCVAwUBR6nA5WITJZieluOzAQLv5wQAksiLpg11ki2ltHzsvFexZGZ/9rlEZvUx
FO2KpNdnMB8t+vSXjzmiWFaHdAx3ygs6K7OWq+IAxGtqWu/SZKsS8WV0G0+En/Hg
8yhxV2xJxU7MP+hSpNVxS90sZ1YW5xOIMD1RPwSmHHTPuc4pZX49m9tzj3ufZQ7m
6YSOGZByBLo=
=KxhZ
-----END PGP SIGNATURE-----