On 10/10/11 2:43 PM, Mariano Martinez Peck wrote:
On Mon, Oct 10, 2011 at 6:50 PM, Yanni Chiu <[email protected]
For the case where a lot of serialized files need to be converted,
having two versions in memory is almost a necessity;
heheheheh how people could live with ReferenceStream for 10 years?
otherwise, the Fuel code update would have to be applied for each
file being converted.
but answer my question: why would you need to update Fuel so frequently ?
I don't need to update Fuel frequently. I'm currently "stuck" at some
pre-1.6 version of Fuel (some combination of package versions that I
managed to get working at the time, using early Fuel releases). I want
to migrate to a newer version at some point (to use some new Fuel
features), but the hold up is that I would have to migrate about a dozen
serialization files - probably manually, since a dozen is roughly at my
threshold to automate. However, I expect that the number of files to
migrate would be a larger number in the future. At that point I'd
automate the: deserialize with old Fuel, update to newer Fuel and
serialize again. The migration procedure seems safer to me, if it did
not load code in the middle of the process. There's lots of workarounds
for this issue, so it's not a high priority.
A separate issue is that at some point I wanted to serialize
something differently, in two different contexts. In one case,
serializing a Pier kernel, I want Fuel to just do its thing. In the
other case, when exporting a portion a Pier kernel, I want to fine
tune (i.e. map to different objects) the objects being
exported/imported. There is a hook to allow the object swap, but the
swap would then take place for the other case of serializing to
whole kernel (where the desired behaviour was for no such mapping).
That's an interesting point....Let me see if I understood. Let's say
that you want to exclude certain instance variables of a class. What you
mean is that you want to apply this hook (or another one) in an specific
serialization and not always? because right now with Fuel (and SIXX, and
I guess StOMP also) since you put the hooks in methods of the class,
they are always taken into account. How would the API for the user
should be? you can you specify for an specific serialization run that
certain hook of certain object/class must be applied and some should not ?
Yes, you've got the idea. No idea what the API should be for such
functionality - probably a serialization context (passed in at the
start) that answers configuration parameters to use to pick an object
mapping method.
Apart from that, do you have a real example where you need such behavior
? Beause it looks quite complex/rare scenario ;)
My serialization code is not top of mind, but I think the issue I had
was that when exporting a portion of a Pier kernel, for importing into
another Pier kernel, the security objects should be nil'ed out. However,
when using Fuel to serialize the kernel, the security objects must be
serialized instead of being nil'ed out. Not sure why I don't currently
have a bug - probably, the security is being inherited from the parent
structures when they're nil. I'll see the problem once I try to set
different security on lower down structures - they'll be lost on restart.
--
Yanni
