Gedcom-Datei parsen

[Sir Rufo]

@Jumpy

Nein habe ich nicht, denn dafür wird bei einem Referenz-Verweis auch ein TRefNode erstellt mit direktem Zugriff auf die referenzierte Node (müsste noch leicht verfeinert werden).

Auf jeden Fall kann man gleich prüfen, ob man diese Referenz schon gespeichert hat, wenn nicht speichert man die.

[Sir Rufo]

Ich glaube ich habe bei der Beschreibung des Zeilenaufbaus einen kleinen Fehler gemacht.

So ist die korrekte Logik für die Zeile

Code:

<LEVEL> -- <SEP> -+- <TYPE> -- <SEP> -+- <DATA> ---+- <EOL>
                  |                   +- <REFTO> --+
                  +- <REF> -- <SEP> -- <TYPE> ------- <EOL>

Wenn die Zeile also eine Referenz ist

Code:

0 @foo@ INDI

dann folgen keine Daten mehr.

Wenn die Zeile auf eine Referenz verweist, dann beinhalten die Daten die Referenz

Code:

0 INDI @foo@

Das müsste also alles falsch sein

Code:

0 @foo@ INDI @foo@
0 @foo@ INDI Some data
0 INDI @foo@ and some data

[Jumpy]

Zitat von Sir Rufo:

@Jumpy
Nein habe ich nicht, denn dafür wird bei einem Referenz-Verweis auch ein TRefNode erstellt mit direktem Zugriff auf die referenzierte Node (müsste noch leicht verfeinert werden).

Auf jeden Fall kann man gleich prüfen, ob man diese Referenz schon gespeichert hat, wenn nicht speichert man die.

Na gut, das Problem ist schon da, aber du löst es bereits bevor es zum Problem wird.

Das kommt ja letztlich daher, dass die Datensätze in beliebiger Reihenfolge in der Datei stehen können und daher dass zirkuläre Referenzen erlaubt sind, d.h. es wäre gar nicht möglich die Daten so zu speichern, dass man daraus die Objekte in einer Reihenfolge erzeugt die bewirkt, das Referenzierte Objekte bereits zuvor erstellt werden.

----------

Kann das sein das

Code:

0 INDI @foo@

auch falsch ist?

Code:

1 INDI @foo@

aber OK?

Muss der Eintrag auf Ebene 0 nicht eine Ref sein, entspricht doch quasi einem Primary Key, den jeder Datensatz braucht?

[Sir Rufo]

Code:

0 INDI @foo@

Ist nicht falsch, aber in dem Kontext unsinnig.

Code:

0 NOTE @foo@

macht schon mehr Sinn

[hansklok]

Zitat von Sir Rufo:

Ausserdem muss man im Zweifelsfall erst die gesamte Datei ausgelesen haben, um auf die Referenzen auch zugreifen zu können.

Da hat Sir Rufo recht!

Zitat von Jumpy:

Wobei ich gerade überlege (ich hab allerdings keine Ahnung von Genealogie-Programmen) dass es eh nicht möglich(?)/einfach ist diese Objekte OOP-mäßig miteinander zu verknüpfen (assoziieren?). Hätte jetzt gedacht, dass die Objekte sortenrein in entsprechenden Collections liegen und in anderen Objekten gerade mal die Referenz-ID auf diese gespeichert wird und man dann die Collection fragen muss: Gib mir mal die Familie mir der ID F12, oder so. (Zumindest die Objekte auf Ebene 0).
Objekte auf höheren Ebenen würden wahrscheinlich mit dem übergeordneten Objekt erzeugt und im übergeordneten Objekt "verwaltet". Referenziert würden die glaub ich ala @I12!P2@ oder so, hab da aber bisher kein konkretes Beispiel für gesehen nur die Spezi so verstanden, das es das geben könnte.

Genauso ist es. Es werden nur die Verweiszeiger, also die ReferenceIDs gespeichert. Alle Hauptobjekte werden in Collections verwaltet (INDI, FAM, SOUR, OBJ, NOTE).

Zitat von Sir Rufo:

Code:

0 INDI @foo@

Ist nicht falsch, aber in dem Kontext unsinnig.

Code:

0 NOTE @foo@

macht schon mehr Sinn

Sir Rufo, da hast Du wiederum recht, allerdings schreibt der Standard explizit folgende Notation für Hauptobjekte außer HEAD und TRLR vor:

0 @I123@ INDI
0 @F123@ FAM
0 @N123@ NOTE
0 @S123@ SOUR
0 @O123@ OBJ

Header und Trailer (kommen einmalig pro Datei vor!):
0 HEAD
0 TRLR

Ich hänge mal den übersetzten Xojo-Code (Basic) ran. Allerdings kommt es zu Exceptions (habe das kommentiert). Auch, was nicht geht. Vielleicht findet Ihr den Fehler.
Achso: Xoxo kennt keine StringBuilder-Klasse. ich habe jetzt einfach einen String definiert und ihm immer wieder die neuen Teile angehängt. Das ist doch dasselbe, oder? Siehe OutputNode().

Danke für diesen angeregten, spannenden Thread.

[Jumpy]

Das fehlende List.Contains(ANode) musst du wohl selber nachbauen, wenn die Collection das nicht kann. Im einfachsten Fall einfach eine Prozedur, der man Collection und Element übergibt und die dann durch alle Elemente iteriert und schaut, ob es das Element schon gibt.

Oder aber Dictionary statt Collection nehmen, vllt. kann das mehr?

[Sir Rufo]

Ja, der StringBuilder ist nur schneller und rührt nicht so im Speicher herum.

Delphi-Quellcode:

LStr := '';
for LIdx := 1 to 1000 do
  LStr := LStr + 'a';
Result := LStr;

ist analog zu

Delphi-Quellcode:

LSB := TStringBuilder.Create();
try
  for LIdx := 1 to 1000 do
    LSB.Append( 'a' );
  Result := LSB.ToString;
finally
  LSB.Free;
end;

[hansklok]

...ach verdammt, ich kriege es nicht zum laufen.

Was wäre denn noch ein Konzept so eine Datei, ressourcenschonend, einzulesen?