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 <yanni@rogers.com> 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