[Allegro] Vb.307 : Ergebnismengen konservieren und rekonstruieren
aresqa allegro
aresqa at gmail.com
Do Jan 31 10:34:42 CET 2019
Verlautbarung 307 zur allegro-Entwicklung 2019-01-24
--------------------------------------------------------
Ergebnismengen konservieren und rekonstruieren
-------------------------------------------------------------------
Eine Frage wurde eingereicht, ob man denn eine Ergebnismenge irgendwie
"konservieren" könne. Der Wunsch ist, genauer gesagt, daß eine gerade
mit einiger Mühe aufgebaute Ergebnismenge genau so und nicht anders
irgendwann später, vielleicht sogar nach Monaten oder Jahren, wieder
hervorgeholt werden könnte. Oder auch, um sie einem anderen Nutzer
zukommen zu lassen, damit der sie einlesen kann und nicht selber
aufbauen muß - das ist ja nicht immer ganz einfach.
Nun kann man zwar schon lange die Liste der internen Satznummern der
aktuellen Erg.Menge mit dem Befehl
write in (s. h xcstring=ix)
hinausschreiben in eine (vorher mit open x xyz.set geöffnete) Datei
xyz.set (s. h xcstring=ix), und bald darauf oder später mit
read set xyz.set (s. h xread=read set)
wieder einlesen - die Erg.Menge ist dann plötzlich wieder da.
Der Haken bei dieser Sache: Es können einige oder alle Sätze falsch
sein! Und zwar dann, wenn zwischenzeitlich eine Gesamt-Erneuerung
gemacht wurde, denn dann kriegen alle Sätze eine neue interne Nummer.
INTERNE Nummer! Die Nummer in #00 bzw. der Primärschlüssel ändert
sich dabei nicht! Denn der Inhalt des Datensatzes bleibt insgesamt
völlig unverändert. Die "interne Nummer" ist diejenige, die unten in
der Statuszeile zu sehen ist, im zweiten Feld von rechts. Da steht
z.B. 10806/2 L288
Das bedeutet: Der Satz hat die interne Nummer 10806, steht in der
Datei 2 und ist 288 Bytes lang. Diese Nummer 10806 kann sich bei
der Gesamterneuerung ändern, aber diese internen Nummern sind es, die
in einer .set-Datei stehen.
Daraus wird klar: für eine Dauer-Konservierung eignet sich die
interne Nummer nicht. Was sich eignet, ist einzig der Primärschlüssel.
Zwar kann man auch diesen mutwillig ändern, aber nur auf eigene
Gefahr, deshalb wird davon abgeraten: er wäre dann u.U. nicht mehr
eindeutig, und eindeutig muß er sein, sonst verliert er seine
wichtigste Eigenschaft. Und nur dank dieser kann man auch die hier
gestellte Aufgabe lösen!
Ergo blieb nichts übrig, als einen neuen FLEX zu schreiben. Was er tun
soll, ist klar: die Primärschlüssel, nicht die internen Nummern, in
eine Datei schreiben. Diese kann ein zweiter FLEX später wieder
einlesen und die zugehörigen (evtl. veränderten) internen Satznummern
dann ermitteln, um damit die Ergebnismenge zu rekonstruieren.
Der neue FLEX heißt "emkon.flx" (von "ErgebnisMenge KONservieren")
und er konserviert die aktuelle Ergebnismenge. Das macht er so:
Er speichert die Primärschlüssel der Sätze in eine Datei xyz.erg,
wobei xyz ein frei wählbarer Name ist, und der Dateityp .erg wurde
für diesen Zweck neu erfunden.
Die erste Zeile dieser Datei ist dann der Titel der Erg.Menge, so wie
er in der Liste (Alt+e) zu sehen ist und auf dem Balken unten rechts,
z.B. also "per shakespeare?" (Der Name der Datei muß nichts zu tun
haben mit dem Titel der Ergebnismenge, der vom Suchbefehl herrührt.)
Man ruft also auf:
X emkon Dann wird man nach einem Dateinamen gefragt.
Der Dateiname ist ganz beliebig, es muß nur ein zulässiger Name xyz
sein, den man einer Datei geben kann, ohne daß Windows aufmuckt.
Noch'n Tip: Der Titel der Erg.menge kann recht lang und komplex werden.
Man kann ihn aber ändern! Um den Namen der aktuellen Erg.Menge zu
ändern auf, sagen wir, "Goethe's Werke", müßte man nur eingeben:
x set RGoethe's Werke
Kaputtgehen kann nichts - es gibt keine Schreibvorgänge in der Datenbank.
ACHTUNG: Die Dateien kommen alle in den Datenbankordner (DbDir), also
z.B. c:\allegro\demo2! Denn es kann sein, daß später mal jemand anders
genau diese Erg.Menge braucht, und dann soll sie ihm ohne Umstände
sofort zugänglich sein.
Natürlich kann man sich eine solche Datei auch sonstwohin
kopieren, wenn man sie auf Nummer sicher haben will.
******
Irgendwann später, vielleicht erst nach Jahren ...
... kommt der Moment, wo man die Erg.Menge wieder braucht.
Dazu muß ein zweiter FLEX ran, der die .erg-Datei einlesen und
die Erg.Menge rekonstruieren kann. Er heißt emrek.flx (von
"ErgebnisMenge REKonstruieren")
Ist der Name der .erg-Datei z.B. "xyz.erg", dann ist zum
Rekonstruieren einzugeben:
X emrek xyz
und nach kurzer Zeit taucht die Ergebnismenge auf, als ob nichts
gewesen wäre, mit dem Titel, den sie beim Konservieren hatte.
Die beiden FLEXe kann man sich abholen:
X gf emkon.flx und X gf emrek.flx
Sie sind vollständig kommentiert, damit sie auch brauchbar sind
als Vorlage für ähnliche Zwecke.
Das Verfahren eignet sich auch für solche Fälle, daß ein Kollege aus
einer anderen Abteilung anruft und eine bestimmte Erg.Menge braucht,
die er selber nicht zustandebringt. Als Kenner der Materie kann man
die Menge rasch zusammenstellen, dann konservieren, den Kollegen
zurückrufen und sagen, "OK Alter, gibt mal ein X emrek xyz!"
Cool, oder?
---------------------------------------------------------------
Am besten, um ein Gefühl dafür zu kriegen, gleich abholen und
ausprobieren. Hier die vollständige Beschreibung eines Beispiels:
DemoBank starten
In Suchbefehlszeile eingeben: all drama?
Ergebnismenge entsteht, links sieht man bei Alt+e als letzte Zeile:
76 : all drama? Das ist der "Titel" der Erg.Menge
Dann diese konservieren, unter dem beliebigen Dateinamen "schauspiel"
X emkon schauspiel
Der Titel und die Primärschlüssel der aktuellen Erg.Menge "all drama"
werden gespeichert in schauspiel.erg
(Den neu ausgedachten Dateityp .erg gab es bislang nicht.)
Merke: Der Dateiname (schauspiel.erg) muß nichts zu tun haben mit
dem Ergebnismengentitel (all drama)
In der Datei schauspiel.erg (schauen Sie rein mit h schauspiel.erg)
steht als erste Zeile der Erg.Mengentitel "all drama?".
So beginnt die Datei:
all drama? Titel der Erg.Menge
378477277 Prim.Schl. des ersten Satzes
875208 Prim.Schl. des zweiten Satzes
...
Danach irgendeine andere Erg.Menge machen oder sonstwas anderes tun,
a99 beenden, neu starten, und dann eingeben:
X emrek schauspiel
Es dauert je nach Umfang einige Sekunden, dabei entsteht die
Erg.Menge, die wieder den Titel 76 : all drama? hat. Und inhaltlich
identisch ist mit derjenigen, die man konserviert hatte. Auch falls
keiner der Sätze noch die alte interne Nummer hätte.
Der emrek.flx hat eine Datei schauspiel.set erzeugt und diese dann
als "PRESTO"-Erg.Menge eingelesen. Sie beginnt so:
all drama? Der Befehl zur Erzeugung der Menge
45 interne Nr. des ersten Satzes
101 interne Nr. des zweiten Satzes
Eben diese internen Nummern können nach längerer Zeit anders lauten,
die Primärschlüssel aber nicht - es sei denn man hat die Nummern in
der #00 verbotener Weise geändert, dann kann's nicht klappen.
ABER was ist, wenn in den Jahren seit Erstellung der Konserve
ein oder mehrere Titel gelöscht wurden?
Dann wirft emrek.flx im Anzeigefeld Meldungen aus:
Satz ... ist nicht mehr da!
wobei ... der Prim.Schl. des nicht mehr auffindbaren Satzes ist.
Evtl. kann man diesen dann, wenn's einen interessiert, z.B. in einer
alten Sicherungskopie wiederfinden. Die neu erstellte Erg.Menge
enthält dann logischerweise nur die noch vorhandenen Datensätze.
Nachwort
Ein Schlauberger könnte jetzt fragen: "Wieso wurden denn nicht gleich
bei der Erfindung der Ergebnismengen in den .set-Dateien die Primär-
schlüssel verwendet und nicht die internen Nummern? Dann hätte man
sich jetzt die Arbeit sparen können für diese neuen FLEXe und hätte
schon längst die Erg.Mengen beliebig lange aufbewahren können!"
Nun, von Sitzung zu Sitzung werden sie ja längst aufbewahrt, wenn in
der .ini-Datei steht
SaveResults=1
Nur nach einer Gesamterneuerung, da stimmen einige Nummern u.U. nicht
mehr. Aber schlimmer noch: Primärschlüssel MUSS man gar nicht haben, es
geht auch ohne. Am Anfang der Entwicklung gab es sie noch nicht!
Erst mit der Erfindung des Updating mußte man sie einführen.
Man kann aber noch heute eine Datenbank ohne Primärschlüssel
konfigurieren und betreiben! Nur updaten geht dann nicht. Konservieren
leider auch nicht ... Ein Grund mehr, vom Verzicht auf Primärschlüssel
abzuraten.
Übrigens werden die Erg.mengen von Sitzung zu Sitzung nicht im DbDir
und nicht in .set-Dateien aufbewahrt, sondern in den cat.*-Dateien im
eigenen Arbeitsverzeichnis. Die haben eine ganz andere Struktur, die
aber auch auf den internen Nummern fußt. Sie sind so konstruiert,
daß der Start einer neuen Sitzung immer schnell geht und nicht umso
länger dauert, je mehr Erg.Mengen man aufbewahrt hat. Das wäre so,
wenn man es mit .erg-Dateien machen würde.
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://bibservices.biblio.etc.tu-bs.de/pipermail/allegro/attachments/20190131/f20fc2d6/attachment.html>
Mehr Informationen über die Mailingliste Allegro