# Serialisierung, FileOutputStream aufteilen



## Rudolf (13. Jan 2011)

Hi Leute,

gleich zwei Fragen.

1. Wenn ich über 


```
FileOutputStream fs = new FileOutputStream("bla.data");
		ObjectOutputStream os = new ObjectOutputStream(fs);
		os.writeObject(objects);
		os.close();
```

eine Objektstruktur abspeichere verfolgt der ObjectOutputStream alle Referenzen von <object> und speichert sie in eine Datei bla.data ab. Gibts eine Möglichkeit in mehrere Dateien abzuspeichern wegen der besseren Übersichtlichkeit? Zumindest in wie fern ist sowas sinnvoll? Könnte mir vorstellen, dass das Sinn macht, indem für jede Klasse eine einzelne Datei bereitgestellt wird.

2. Mit deren oberen Methode speichere ich ja das gesamte Objekt mit all seinen Referenzen ab. Gibt es eine Methode, die mir hilft nur das wegzuspeichern, was sich wirklich in der Objektstruktur verändert hat, anstatt alles komplett wegzuspeichern? Ich habe von sowas mal gelesen und es soll in "Java Algorythm" beschrieben werden.


----------



## fastjack (14. Jan 2011)

zu 1: Inwieweit es sinnvoll ist, zu einem Objekt mehrere Dateien zu schreiben, weis ich nicht. Du kannst aber die Methoden, die letztendlich die De/Serialisierung übernehmen überschreiben und Deine eigenen Serialisierungen vornehmen.

zu 2: Bei der Serialisierung wird ja der ganze Objektzustand gespeichert, um ihn dann in einem frischen System wieder komplett herstellen zu können. Wenn Du nur Änderungen der Zustände speichern willst, dann Änderungen zu was, zu Zustand 1, 2, 3 oder 15? Wenn Du nur "schlankere" Dateien erzeugen willst, dann geht es wie bei 1)


----------



## Rudolf (14. Jan 2011)

Was heißt hier Zustände? Ich will keine ganzen Zustände wegspeichern, sondern nur Änderungen wegspeichern, die wirklich gemacht worden sind. Wenn keine Datei existiert, soll die ganze Objektstruktur abgespeichert werden. Wenn eine Datei existiert und ein Zustand der Objektstruktur bereits weggespeichert wude, und eine Änderung in der Objektstruktur gemacht wurde, soll nur der Teil der Änderung in der Datei verändert bzw aktualisiert werden und der Rest nicht.

Ok das mit der Aufteilung macht wirklich keinen Sinn. Daher streichen wir den Punkt. Hätte mich nur interessiert welche Punkte dafür und welche dagegen sprechen. Wenn jdm dazu noch was Sinnvolles auffällt, kann er bitte mal ein paar Gedanken zu geben, aber ansonsten lasst uns lieber auf diesen Aufteilungsmechanismus aus Punkt 2 beschränken.


----------



## Rudolf (16. Jan 2011)

Ok nochmal der Versuch.

Es gibt einen Algorythmus, der bewirkt, dass man über die Seriliaiserungsmehtode mit writeObject() und den Fileinput und Objectoutput Objekten nicht die gesamten objektstrukturen wegspeichert, sondern nur diejenigen Objekte, die sich wirklich verändert haben im vergleich zum letzten Speicherzustand. Diesen Algorythmus suche ich. Wäre echt geil, wenn sich dazu mal jmd melden könnte, der Ahnung hat


----------



## fastjack (16. Jan 2011)

Wenn in einem Objekt O ein Attribut auf XYZ gesetzt ist, dann ist das leider ein Zustand von O. Du schreibst ja selbst von Speicherzuständen   Der Zustand des Objekts, also aktuelle Variablenbelegungen etc. werden mit der Serialisierung neben seiner Struktur gespeichert.
Den gesuchten Algorithmus kenne ich leider nicht, aber Du schreibst ja, daß es ihn gibt  Du kannst die Serialisierung insoweit beeinflussen, das Du sie selbst implementiert, indem Du die entsrepchenden Methoden einfach überschreibst.


----------



## Murray (17. Jan 2011)

writeObject schreibt immer das gesamte Object mit dem Ziel, dass das Object durch readObject vollständig rekonstruiert werden kann. Insofern kann es denn von Dir postulierten Algor*i*thmus i.A. nicht geben. Auf der Anwendungsebene kann man das aber sicher irgendwie realisieren - aber warum? Vielleicht könntest uns noch Details zu Deinem Anwendungfall liefern.


----------



## fastjack (17. Jan 2011)

> Wäre echt geil, wenn sich dazu mal jmd melden könnte, der Ahnung hat



Gerade jetzt, wo man sie am dringendsten braucht, melden sich Herr K. und Icke_ leider nicht mehr 

Ich denken Du wirst auch schwere Probleme beim Einlesen eines solchen serialisierten Objekts haben. 

Beispiel:


```
class Foo() implements Serializable {
    String s;
    int i;
    Foo(String s, int i) {
        this.s = s;
        this.i = i;
    }
}
```

Anfangszustand: ein Foo("a", 1) F1 erzeugen und serialisieren (eine Datei)
Foo wird geändert: F1.s="b", Änderungen serialisieren (neue Datei erzeugen, alte ändern?)
Foo wird geändert: F1.i=4711, Änderungen serialisieren (Änderungen zusammenfassen, getrennt speichern? ...)
Neustart: F1 soll eingelesen werden. Was soll jetzt eingelesen werden? Im Prinzip müßten alle Dateien nacheinander gelesen werden, da ja unterschiedliche Änderungen in verschiedenen Feldern möglich sind.

* Was passiert bei Strukturänderungen?
* Wie sieht es in der Tiefe aus? Also Foo besitzt noch eine Liste mit Bars, die wiederum Apfelobjekte enthalten...

... ein komplexes Thema.


----------



## Rudolf (27. Jan 2011)

Ok ihr habt mich überzeugt. 

Danke für die Informationen. Das hat sich erledigt.


----------

