Strukturierte Pickler
Von: Patrick Roemer (sangamon@netcologne.de) [Profil]
Datum: 21.09.2006 15:43
Message-ID: <eeu4o9$hgf$1@newsreader2.netcologne.de>
Newsgroup: de.comp.objekt
Datum: 21.09.2006 15:43
Message-ID: <eeu4o9$hgf$1@newsreader2.netcologne.de>
Newsgroup: de.comp.objekt
Hallo,
schaun mer mal, ob hier ueberhaupt noch wer liest... :)
Eigentlich moechte ich 'nur' Exemplare einer teilweise hierarchisch
komponierten Familie von Objekten serialisieren und deserialisieren.
Hinzu kommt, dass ueber der serialisierten Struktur Traversierung mit
beliebigen Aktivitaeten moeglich sein soll. Das Serialisierungsformat
wird im Laufe der Zeit vermutlich Aenderungen durchmachen; die
Applikation muss in der Lage sein, unterschiedliche Versionen einzulesen
und mindestens die 'aktuelle' Version zu schreiben. Ich brauche also
strukturierte, agile Pickler oder sowas. ;)
Ich versuche mal, das an einem an den Haaren herbeigezogenen Beispiel zu
verdeutlichen. Gegeben sei eine Baumstruktur:
class Node {
int[] payload;
Node left;
Node right;
}
Da koennte es nun diese Pickler zu geben:
PInt : schreibt ein int
PList<T>: schreibt die Elementzahl als PInt, die Elemente mit dem T
zugeordneten Pickler
PRef<T>: schreibt die Adresse des referenzierten Blocks innerhalb der
Datei als PInt
PNode: Kompositum aus PList<int> und zweimal PRef<Node>
Diese In-Memory-Struktur...
[4,5,6] bzw.: ([4,5,6],([1,2,3],-,-),([7],-,-))
/ \
/ \
[1,2,3] [7]
...koennte z.B. so serialisiert werden:
3 4 5 6 8 15 0 0 3 1 2 3 -1 -1 0 1 7 -1 -1 Wert
00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 Datei-/Streamindex
|---------------| |---------------| |---------|
Soweit so gut. Nun moechte ich aber z.B. defragmentieren, in zwei
Schritten. (Noch mal: Das ganze Anwendungsbeispiel ist willkuerlich an
den Haaren herbeigezogen.)
Schritt 1:
3 4 5 6 8 15 3 1 2 3 -1 -1 1 7 -1 -1 0 0 0 Wert
00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 Datei-/Streamindex
|---------------| |---------------| |---------|
ID-Mapping: 0->0, 8->6, 15->12
Schritt 2:
3 4 5 6 6 12 3 1 2 3 -1 -1 1 7 -1 -1 0 0 0 Wert
00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 Datei-/Streamindex
|---------------| |---------------| |---------|
Also muesste man ueber die Pickler auch in der Lage sein, Blocks zu
kopieren, IDs gezielt neu zu schreiben, etc., also eben die
serialisierte Struktur zu traversieren. Dazu koennte man sich jetzt noch
vorstellen, dass die Liste urspruenglich nicht mit einer Laenge sondern
mit einem in-band-Terminator (Integer.MIN_VALUE) geschrieben wurde, und
ints nur mit zwei bytes. (Again: Haare/herbeigezogen.) Spaeter wurde
dann auf obiges Format umgestellt, die Applikation muss die alte Version
aber zumindest noch lesen koennen. Es koennte natuerlich auch extremere,
strukturelle Aenderungen geben, so dass z.B. eine Node komplett anders
zusammengesetzt ist, als in der Vorgaengerversion.
Das waeren die Anforderungen. Darueberhinaus sollte der ganze Spass noch
performant und 'schoen' (insbesondere wartbar) sein. Kennt vielleicht
jemand klassische Muster fuer eine solche Struktur?
Meine bisherigen Ansaetze waeren:
- Methoden fuers Lesen und Schreiben in Codec-Objekten, die zwischen
Versionen variierenden Teile werden noch mal in eigene, polymorphe
Marshaller ausgelagert. Das loest aber z.B. nicht das Problem der
generischen Traversierung - die Struktur liegt ja nicht deklarativ vor,
sondern nur z.B. als Schleife in den read/write-Methoden.
- Die Pickler als Visitables ohne Zustand/Verhalten, Traversierung, etc.
wird alles ueber Visitors geloest, die intern als Zustand Objekt
und/oder Stream halten. Das koennte zwar halbwegs klappen (hab's aber
noch nicht ausprogrammiert), ist aber bestimmt alles andere als
performant, ob's les-/wartbar waere, wage ich auch zu bezweifeln.
Hat irgendwer einen Hinweis? Muss kein Paper oder Literaturtip sein, mir
wuerde schon ein schlauer Suchbegriff reichen...
Viele Gruesse,
Patrick
[ Auf dieses Posting antworten ]
