[Allegro] & noch etwas für V34.1

Di Apr 1 12:20:30 CEST 2014

Es jährt sich heute der Tag des ersten Spatenstichs zu einem neuen
Speichergebäude, und die Eröffnung steht unmittelbar bevor.
Den Nachmorgen des Letzten März haben wir oft und gern genutzt zur
Bekanntgabe neuer Entwicklungserträge. So auch heute.

Datenbanken sind zum Speichern da. Aus einem Speicher will man, was
drin gespeichert ist, jederzeit in gutem Zustand wieder herausholen
können und das auf einfache, schnelle Weise, mit der beruhigenden
Gewißheit, daß es sicher und dauerhaft untergebracht ist.
Aus diesen schlichten Überlegungen erwuchsen schon früh die ersten
Wunschvorstellungen, nicht nur Feldfrüchte, Waffen und Munition
für einen späteren Bedarfsfall einlagern und dann rasch hervorholen
zu können, sondern auch Gedanken, Ideen, Erinnerungen und Erkenntnisse.
Denn die Speicherfähigkeit und, ja, auch die physische Persistenz des
menschlichen Gedächtnisses wurde bald nach der Entwicklung des
Großhirns schon als unzureichend empfunden. Die feste Bindung von
Inhalten an bestimmte Individuen, z.B. Homer oder Aristoteles, war
immens unbefriedigend.
Damit war der Keim zur Datenbank-Idee gelegt. In den Äonen seit der
Zeit der ersten Keilschrifttäfelchen haben sich die Mittel und Methoden
gewaltig gewandelt. Immer aber boten neben der Technik auch Art und
Umfang der Speichermöglichkeiten sowie deren Effizienz, Vielseitigkeit,
Geschwindigkeit und vor allem die Suchverfahren viele Anreize für neue
Entwicklungen. So sind die Keilschrift-Buchhaltungen längst den Excel-
Tabellen gewichen, Don Giovannis Leporello-Register dem Adressen-
speicher im Smartphone, sowie der Zettelkatalog, und damit sind wir
beim Thema: der allegro-Datenbank.
Unbefriedigend an einer allegro-Datenbank ist - nein, war - bisher noch
der Fakt, daß nur eigentliche Datenbankinhalte, genauer gesagt, die
Datensätze, ein hohes Maß an Dauerhaftigkeit besitzen. Sie werden durch
die eingebauten Verfahren der Datensicherung geschützt und der Index
sowie die Kurzliste sind sogar regenerabel. Aber um alles andere muß
man sich separat mit anderen Mitteln kümmern. "Alles andere", das sind
Daten und Angaben aller Art, die sich keineswegs alle in Datensätzen
würden abbilden lassen und damit gleichermaßen in Sicherheit bringen
und bequem kontrollieren. Zum Gesamt einer Datenbank, damit sie rundum
gute Dienste leistet, gehört eben doch weit mehr als der Inhalt
der Datensätze! Man braucht verschiedenste Adressendaten, Tabellen und
Listen für allerhand Zwecke, Meldungstexte, Protokolle von Vorgängen
wie etwa Entleihungen und Sitzungsabläufen, und jedem fällt noch stets
mehr ein, was irgendwie gespeichert werden müßte und immer bei der Hand
sein sollte.
Aus der Sicht des FLEX-Programmierers ist von Interesse, daß nur ein
Index auch dynamische Inhalte aufnehmen kann, die dann an allen Plätzen
verfügbar sind, de facto also als ein allen a99-Instanzen gemeinsamer
Variablenspeicher.
Dieser gesamte Komplex von Unzureichlichkeiten kann nun quasi mit einem
Rundumschlag als gelöst gelten, und hier beschreiben wir die Neuerung,
verfügbar mit V34.1 ab morgen:

Der PersistenzSpeicher oder auch PowerStore (PS)
------------------------------------------------

Zum persistenten (sitzungsuebergreifenden) Speichern von Inhalten, die
ein allegro-Betrieb braucht, neben den eigentlichen Daten in den
zugehörigen Dateien, eignen sich bisher mehrere Methoden, die in
ihrer Gesamtheit aber eben doch kein komplettes Leistungsspektrum
für eine universelle Persistenzspeicherung bieten:

1. ViewListen (vornehmlich Auswahllisten für die Dateneingabe)
2. Schlichte Textdateien (mit aresqa oder "var Fdateiname" zu nutzen)
3. $-Variablen: Speichern und Rückholen mit
     $0>dateiname : die kleinen Variablen speichern
     $1>dateiname : die grossen Variablen speichern
     X dateiname  : einen Satz Variablen laden
4. Mit  ixadd  kann man Zeichenfolgen auch in jedem beliebigen
    Register der Indexdatei speichern, mit ixdel loeschen.

Die Methode 4 birgt wohl schon ein gewisses Potential, weil man im
Index groessere Mengen Daten fuer einen gezielten, schnellen Zugriff
bereitstellen kann. Der enorme Nachteil von "ixadd" ist jedoch, dass
die so gespeicherten Daten nach einer Index-Erneuerung weg sind. Diese
Art der Aufbewahrung kann man also keinesfalls "persistent" nennen.
Immerhin haben wir aber die Möglichkeit, mehrere Indexdateien einer
Datenbank zuzuordnen, und es könnte doch - so der neue und eigentlich
verblüffend einfache Denkansatz - eine oder mehrere davon für andere
Inhalte vorgesehen werden statt nur für die Suchkriterien der
Datensätze! Und nur Indexdateien sind prädestiniert für das Speichern
und schnelle Auffinden von vielen Millionen textuellen Angaben.

Wir haben deshalb die Methode 4 ein wenig aufgewertet und ihre
Nutzung mittels FLEX stark vereinfacht.
Dazu braucht man zuerst eine speziell präparierte, leere Indexdatei
namens  cat.azx, die man schlicht in das eigene DbDir kopiert. Sie wird
im Ordner DEMO2 mitgeliefert und natürlich stets frisch auch per FTP
beziehbar sein.
Man kopiert sie auf den Namen  kat.bzx, wenn man z.B. mit b.cfg und
kat.bpi statt mit a.cfg und cat.api arbeitet. Sofort danach steht die
neue Methodik in a99 (V34.1) bereit, sogar ohne Neustart.

Die Nutzung erfolgt genau wie bei den $-Variablen, man setzt in die
Befehle nur das Zeichen & ein statt des $. Eine "PersistenzVariable"
(PV) kann jeden beliebigen Namen tragen. Ohne Leer- und Sonderzeichen,
wie sich wohl von selbst versteht; wir wollen ja nicht die Fehler der
Betriebssystemfürsten wiederholen.
Die gesamte Länge einer PV (Name+Inhalt) ist auf 254 Zeichen begrenzt -
das liegt an den grundsätzlichen Eigenheiten der Indexspeicherung.
Braucht man mehr, teilt man den Inhalt geschickt auf mehrere PV auf.

Und so geht man um mit dem PS:
(nochmals, man braucht sich nur zu merken: & statt $)

1. Variable belegen
var "xyz"    oder    var "&abc xyz"
ins &abc             ins

speichert die Zeichenfolge "xyz" in der PersistenzVariablen abc. (Falls
die schon existiert, wird sie überschrieben - wie bei den $-Var.)
Auch manuell geht es: Ins Schreibfeld z.B. eingeben

x &Oktoberfest=20.9.2014   oder   x var "20.9.2014"\ins &Oktoberfest
   oder auch  oder   x var "&Oktoberfest=20.9.2014"\ins

2. Variable nutzen
var &abc   kopiert "xyz" in die iV.

Innerhalb eines var- oder write-Befehls kann man &-Variablen
genauso verwenden wie $-Variablen, d.h. zwanglos einbauen in ganz
beliebige Zeichenfolgen, z.B.:

x var "Das Oktoberfest ist am " &Oktoberfest "!"\mes

3. Variable loeschen
var ""
ins &abc

Und so geht man vor, wenn der PV-Name seinerseits in einer
Variablen steht, z.B. in $AV (oder sogar &AV), und der Wert in #uxy

1. Belegen
var "&" $AV "=" #uxy      oder    var "&" &AV "=" #uxy
ins

2. Nutzen
var "&" $AB
var

3. Loeschen
var "&" $AB
ins

Genutzt wird automatisch das Register 1 der Indexdatei  cat.azx.
Natuerlich kann man auch hineinschauen, wie in jedes Register:

x ind ~z1

Oder sich einen Auszug zeigen oder ausgeben lassen:

x qrix 100 ~z1\show IV

Wenn man nun aber gerne mehrere persistente Speicher haette?
Dann z.B. Register 2 einschalten mit  set &z2
Von dem Moment ab spielen sich alle PS-Aktionen mit dem
Register 2 der cat.azx ab. Bis der nächste Befehl  set &  kommt.

Und Sie erraten es: Mit  set &y1  kann man auch auf eine
weitere Indexdatei  cat.ayx  ausweichen. Auch diese braucht nur
vorher als Kopie der leeren  cat.azx  bereitgestellt zu werden.

Mit guten FLEX-Kenntnissen malt man sich leicht aus, wie man im
PS nun z.B. auch große, dynamische Auswahllisten unterbringt und
verfügbar macht, oder variable Fakten aller Art, die etwa im
_start.flx automatisch aktualisiert werden können, gern mit
Nutzung von Web-Inhalten.

Was aber tun, diese Frage wird kommen, wenn man eine Index-Erneuerung
macht? Vorher den Sonder-Index in Sicherheit bringen und hernach
wieder herbeiholen? Nicht nötig! Eine Indexdatei, für die die Parameter
keine Einträge erzeugen (nur dafür hat man theoretisch Sorge zu tragen)
bleibt automatisch unberührt.
Was ist mit der Datensicherung? Dabei werden alle Dateien des Typs
*.a?x gesichert, auch dafür braucht man keinen Finger zu krümmen.
Kann man gelegentlich mal kompaktieren? Ja, das funktioniert mit jeder
Indexdatei, auch wenn sie mit den Parametern nichts zu tun hat.

Und das war's schon! Anreiz genug, wie wir denken, nun doch für 2014
zu abonnieren, wenn das noch nicht geschehen ist ...

B.Eversberg
(sich zurückziehend zu den letzten Testarbeiten und zum Schnüren des
Gesamtpakets V34.1)