On Tue, Oct 11, 2011 at 2:33 AM, Yanni Chiu <yanni@rogers.com> wrote:
On 10/10/11 2:43 PM, Mariano Martinez Peck wrote:
On Mon, Oct 10, 2011 at 6:50 PM, Yanni Chiu <yanni@rogers.com
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).
You are an early adopter!!! cool :)
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.
Exactly. That's what I meant. From my point of view it is easier to provide such scripts rather than to find a complex automagic conversion between versions. Imagine something like: FuelMigrator migrateFromFuelVersion: '1.6' to: '1.7 streams: aListOfStreams basically it can use gofer/metacello to load the version of fuel, iterate over each file and serialize/materialize.
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.
Interesting. I will open an issue for this.
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.
Well...that can be simple workarrounded with a simple if depending on what you want. So depending what you do, you can serialize or not the security objects. This can be done without needing what you say. It may not be the best solution, but a workarround.
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.
Ok. Check: http://rmod.lille.inria.fr/web/pier/software/Fuel/Hooks http://forum.world.st/Any-serializer-can-customize-serialization-strategy-td... Cheers
-- Yanni
-- Mariano http://marianopeck.wordpress.com