I have some classes which I need to serialize and deserialize. The problem is that they have unserializable parts (e.g., Func instances). Accordingly, I have set up code which must run before serialization to set up memory of what these things should be set to, and post-deserialization code which restores them to the proper values.
However, this is a framework, so I'm kind of in the position of documenting the class with a big warning that says, "Yes, this class is marked @Serializable, but don't do that, use this other method instead or nasty things will happen!".
It would be nice if there were Obj methods preSerialize and postSerialize that writeObj and readObj would guarantee to call. I guess that readObj would have to have another (optional) argument which would be some kind of run-time context (e.g., a map from name to Func). Not having this ability prevents a { simple = true } implementation for my current code.
Is there a better alternative, or a workaround for now?
brianSat 23 Oct 2010
The way it is designed is that you do it all in your constructor and just allow the deserialized fields to be passed in via an it-block. This is discussed a bit in ticket 1036.
Have you tried that?
yachrisWed 27 Oct 2010
Somewhat... it's still ugly, alas.
Here's a bit more on what I'm trying to do. Importantly, this is going to run for days, possibly weeks; having a good checkpoint strategy is important.
I want to serialize/deserialize a bunch of structures. They all refer to various other objects, in particular shared instance objects, that is, it's important that everyone point to the same instance, not a copy (it's all single threaded). So now I have to rebuild the shared structure, deserialize the instances, and then tell them about the shared structure.
The shared structure can't be a singleton since it's mutable, and the things it points to (the other shared things) are mutable so they can't live in a singleton either.
So the "constructor called by the serialization inside Fantom" won't work for me.
More (in some ways) important, to serialize the guys I have to save, I need to make a serializable version of their setup; but it's not cheap to do, and the guys needing to be serialized come and go, so it only makes sense to serialize them when I absolutely have to. SO, having a preSerialize routine that's automagically called before serialization would be fantastic... each object could do its setup then.
Given the shared structures mentioned earlier, the postSerialize routine probably won't help in this case.
OH YEAH... while we're on the subject of XStream, it does keep track of object references; this might let me dump the whole universe, and reload it properly. I'll try it out.
brianWed 27 Oct 2010
That may be a bit beyond what serialization is intended for since it explicitly targets tree structured data, not graphs.
One simple way to turn a graph into a tree, is to use some identifier like a Str or Uri to cross-reference you non-containment objects. Then Fantom serialization should work well.
yachris Sat 23 Oct 2010
I have some classes which I need to serialize and deserialize. The problem is that they have unserializable parts (e.g.,
Func
instances). Accordingly, I have set up code which must run before serialization to set up memory of what these things should be set to, and post-deserialization code which restores them to the proper values.However, this is a framework, so I'm kind of in the position of documenting the class with a big warning that says, "Yes, this class is marked @Serializable, but don't do that, use this other method instead or nasty things will happen!".
It would be nice if there were Obj methods
preSerialize
andpostSerialize
thatwriteObj
andreadObj
would guarantee to call. I guess thatreadObj
would have to have another (optional) argument which would be some kind of run-time context (e.g., a map from name to Func). Not having this ability prevents a{ simple = true }
implementation for my current code.Is there a better alternative, or a workaround for now?
brian Sat 23 Oct 2010
The way it is designed is that you do it all in your constructor and just allow the deserialized fields to be passed in via an it-block. This is discussed a bit in ticket 1036.
Have you tried that?
yachris Wed 27 Oct 2010
Somewhat... it's still ugly, alas.
Here's a bit more on what I'm trying to do. Importantly, this is going to run for days, possibly weeks; having a good checkpoint strategy is important.
I want to serialize/deserialize a bunch of structures. They all refer to various other objects, in particular shared instance objects, that is, it's important that everyone point to the same instance, not a copy (it's all single threaded). So now I have to rebuild the shared structure, deserialize the instances, and then tell them about the shared structure.
The shared structure can't be a singleton since it's mutable, and the things it points to (the other shared things) are mutable so they can't live in a singleton either.
So the "constructor called by the serialization inside Fantom" won't work for me.
More (in some ways) important, to serialize the guys I have to save, I need to make a serializable version of their setup; but it's not cheap to do, and the guys needing to be serialized come and go, so it only makes sense to serialize them when I absolutely have to. SO, having a
preSerialize
routine that's automagically called before serialization would be fantastic... each object could do its setup then.Given the shared structures mentioned earlier, the
postSerialize
routine probably won't help in this case.I may wind up using the XStream serialization library because I've used it before, and it works well.
OH YEAH... while we're on the subject of XStream, it does keep track of object references; this might let me dump the whole universe, and reload it properly. I'll try it out.
brian Wed 27 Oct 2010
That may be a bit beyond what serialization is intended for since it explicitly targets tree structured data, not graphs.
One simple way to turn a graph into a tree, is to use some identifier like a Str or Uri to cross-reference you non-containment objects. Then Fantom serialization should work well.