(From the discussion at Pharo Users mailing list.)
- Install in both Pharo 1.4 and Pharo 6.1 the Fuel version 1.9.4 for debugging:
(ConfigurationOfFuel project version: '1.9.4') load: #(default FuelDebug FuelPreview).
- Analyze the Fuel serialization of the root object myDatabaseObject in the Pharo 1.4 image:
FileStream forceNewFileNamed: 'debug.fuel' do: [:aFile | FLSerializer newDefault setDebug; serialize: myDatabaseObject on: aFile binary]. FLDebugSerialization last log inspect.
-
In the inspected Fuel-Log, look for the FLCompiledMethodCluster, which told me in which classes I use BlockClosures which fuel wants to persist.
-
Changed the source code and the live objects where you use persisted BlockClosures to only use "clean" BlockClosure and only fuel-store them as Strings (Using fuelIgnoredInstanceVariableNames) an recompile them when the instance is materialized (Using fuelAfterMaterialization).
-
If you use sorted collections, then you need to find a workaround. In my case I easily could do this: Search for usages of SortedCollection and made sure, that there is no sortBlock but only the default sort behaviour.
-
Go to Pharo 6.1, load your application code. You might have to deal with the code changes from Pharo 1.4 to Pharo 6.1, for example there will be no TimeStamp class anymore, and similar stuff. Lots of work, but not a Fuel topic.
-
When materializing in Pharo 6.1 use this code:
| fuelFile myDatabaseObject | fuelFile := 'debug.fuel'. myDatabaseObject := (StandardFileStream oldFileNamed: fuelFile do: [:aFileStream | (FLMaterializer newDefault migrateClassNamed: #MethodContext toClass: Context; materializeFrom: aFileStream binary)] ) root. " ... Do with db whatever you need ... "
THE HAPPY END