Maybe the way to go is to provide a metadescription of the changes done to the format since last version. That way, you can use it to convert your serialized objects from one version to another (even back and forward). That's what I think databases do, if you update your version, you have to update the database. It seems like a less effort approach.
Cheers! Pocho. On Mon, Oct 10, 2011 at 1:50 PM, Yanni Chiu <[email protected]> wrote: > On 08/10/11 6:03 PM, Stéphane Ducasse wrote: > >> Mariano >> >> >> No, that's impossible, and if posible, it is not worth it. >>> Migrating from an old format to a new one is extremelly complicated >>> and innecessary. The easiest way to solve this is to take the >>> correct version of Fuel, materialize the graph from the stream, >>> load new version of Fuel, and seriaize it again. That the easiest, >>> more secure, and more practical approach I can see. >>> >> >> It would be interesting to see if you can get two different versions >> in memory :) (a need for a module system) so that you can load with >> one and save with the other. >> > > For the case where a lot of serialized files need to be converted, having > two versions in memory is almost a necessity; otherwise, the Fuel code > update would have to be applied for each file being converted. > > 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). > > -- > Yanni > > > -- Lic. Javier Pimás Ciudad de Buenos Aires
