[Allegro] if diff und obj 2

[Thomas Berger]

Lieber Herr Eversberg,

>> Gut dass Sie nachhaken: Ich meinte "rst", weil das dem "Rec" irgendwie
>> zugeordnet ist, wird etwa Rec auf Rec1 kopiert, dann auch rst nach rst1.
>> Ein erster Schritt sollte wirklich sein, das in das Objekt
>> hineinzuziehen, dann ist ja fuer den Bereich fast garantiert, dass keine
>> Inkonsistenzen auftreten.
>>
> Es ist und bleibt problematisch, weil die interne Sequenz der Sätze eben
> kein Array von RECORD-Objekten ist. So muß es aber leider bleiben, weil
> wir sonst keine beliebig große Offline-Datei haben könnten bzw. deren
> Verwaltung schwieriger wäre.

Evtl. sind die Anforderungen an den sitzungsuebergreifenden Speicher /
echte "Offline"-Dateien andere als an die Auslagerung von in dieser
Sitzung "angefasster" Datensaetze, wobei Sie letzte als RECORD-Objekte
halten? Ich bin mir nicht sicher, ob die ueberhaupt ausgelagert
werden muessen, selbst wenn man mit a99 eine Million Datensaetze in
einer Sitzung anfasst, sollte der normale Arbeitsspeicher-Auslagerungs-
mechanismus des Betriebssystems noch gut (=performant) damit klar kommen.
Ansonsten muessen Sie halt die RECORD-Objekte serialisieren, aber
natuerlich einen Cache-Mechanismus implementieren: vorsorglich wegschreiben
mag ja o.k. sein, aber staendig wieder einlesen muss nun wirklich nicht
sein. Wenn Sie im Sinne eines Sitzungsprotokolls sequentiell wegschreiben,
koennen Sie auch attraktive undo-Funktionen implementieren. Am Ende
einer Sitzung muessen solche Protokolle aber wohl "konsolidiert"
werden, meinen Sie das mit "schwieriger"?

BTW: Der Offline-Speicher ist nach diversen Flags filterbar, wobei
das als verschiedene Funktionen an verschiedenen Orten angeboten wird.
An einer Stelle ist die Namensgebung m.E. zu eng beieinander:

* Button "Q: Daten in Bearb." liefert alle in der Sitzung bearbeiteten
  vgl. xshow.rtf bei "offline"

* Menue "Extras" -> "In ARBEIT befindl. Saetze" liefert davon die
  Teilmenge, die aktuell "EDT" sind, also noch nicht gespeicherte.
  vgl. xfind.rtf bei "find edit"



> Wir suchen eine andere Lösung. Das Arbeiten mit Objekt 2 ist für die
> Ihnen vorschwebenden Aufgaben zu problembehaftet.


Ich kann den "use case" ja einmal skizzieren, eine Art verallgemeinertes
Update:

Es kommt eine Datei mit "Annotationen", die nach Datensaetzen und -feldern
in irgendeinem Format organisiert ist. Das kann strukturell als .ADT-Format
angenommen werden, Zeichenformat natuerlich nie allegro-OSTWEST. Die
Felder sind irgendwelche identifizierenden Angaben (Identifier, Titel)
und das zu Ergaenzende, normalerweise keine vollgueltigen Aufnahmen,
evtl. aber ausreichend, um notfalls ein Rumpfkatalogisat zu erzeugen.

Es wird davon ausgegangen, dass sich in der Regel zu diesen Daten in der
Datenbank existierende Saetze zuordnen lassen, aber nicht anhand der
Primaerschluessel.

Es existieren in dieser Datei Verknuepfungen der Saetze untereinander,
die deren Identifier nutzen, diese muessen waehrend des Vorgangs auf
allegro-taugliche Nummern umgesetzt werden, also etwa auf allegro-
Identnummern von Saetzen, die erst im Laufe des Vorgangs erzeugt worden
sind (im allgemeinen erfordert das ein zweistufiges Verfahren, es gibt
aber eine relevante Teilklasse von Entstehungszusammenhaengen, wo eine
toplogische Sortierung der Daten garantiert ist und es auch in einem
einzigen Durchlauf gemacht werden kann)

Fuer jeden einzelnen "Satz" der Fremddatei ist daher nacheinander vorzunehmen:

 * "Einlesen" mit Zeichenumwandlung

 * "Aufteilung" in Felder (ich nutze dafuer einen frischen Datensatz und
   "insert")

 * Aufbereitung der Felder (etwa "Umverknuepfung") unter Nutzung der
   Datenbank: Schleife ueber alle Felder der provisorischen Aufnahme,
   ggfls. auch Teile davon (Unterfelder, Reihungen) und Austausch
   von Information.
   (erfordert ein oder mehrere find, die tendenziell eine Ergebnismenge
   produzieren und den Neusatz aus obj1 verdraengen, daher wird der
   von mir vorher nach obj2 gerettet. Mit freien Variablen laesst sich
   hier hervorragend ein Cache realisieren, d.h. die Sache ist ziemlich
   flott)
   Manipulation eines Satzes, ueber den man gerade feldweise iteriert,
   ist gewiss problematisch, im Prinzip muesste er waehrend des
   Prozesses in ein weiteres Objekt ueberfuehrt werden, das anschliessend
   den Satz ersetzt.

 * Ermitteln, ob ein zugehoeriger Datensatz in der Datenbank bekannt ist
   (erfordert ein oder mehrere find, die tendenziell eine Ergebnismenge
   produzieren und den Neusatz aus obj1 verdraengen, daher wird der
   von mir nach obj2 gerettet).
   Wenn ja, um Informationen aus dem externen Satz anreichern (normalerweise
   differenzierter als mit den klassischen Update-Modi, wie sie auch
   "copy obj" implementiert: Gewisse Felder sollen nie ersetzt werden,
   andere nie ergaenzt, dritte dafuer unbedingt aktualisiert werden
   Der vorige Schritt hat dazu eine datensatzbezogene, differenzierte
   Feldliste angelegt, die nun abgearbeitet wird.

   Der naive Ansatz waere, sich zuerst um die Identifizierung zu kuemmern,
   und dann, waehrend Extern- und Online-Satz parallel im Arbeitsspeicher
   vorliegen, die Aufbereitung und Ueberfuehrung zu veranstalten. Wegen
   der erforderlichen Nachladungen und Konsultationen weiterer Datensaetze
   ist dafuer aber irgendwie nicht die Kapazitaet.

*  Speichern

Tendenziell kann hier in allen Phasen auch noch Bedarf bestehen, mit
dem Benutzer zu interagieren, etwa wenn es irgendwo mehrere Moeglichkeiten
zur Auswahl gibt und jemand entscheiden muss, was ersetzt oder
womit verknuepft werden soll.

viele Gruesse
Thomas Berger