[Pharo-project] class rename and Fuel
Here's my scenario: - a Pier kernel was previously serialized with Fuel-1.7 - a class was re-named (happens to be a subclass of PRCommand) - get a walkback when trying to de-serialize with the same Fuel-1.7 - define the missing class, then de-serialize works I was hoping that, after serializing the Pier kernel again (with both classes present, to be able to load), then on the next re-start, the old class would no longer be needed. That did not work - same problem of FLClassNotFound. To debug this, I de-serialized in a development image. To my surprise, evaluating "OldClass allInstances" found 0 instances of the OldClass. So I can't figure out how to track down why Fuel is still looking for that old class. BTW, since Pier looks for all subclasses of PRCommand, I made the NewClass a subclass of Object. That did not fix the problem. Any ideas why Fuel is looking for OldClass, yet there are no instances of OldClass in the de-serialized object graph. The stack trace is included at the end. -- Yanni ===== stack trace ===== [FLClassNotFound new signal: 'Class ' , className , ' not found at materialization'] in FLGlobalClassCluster(FLGlobalCluster)>>materializeGlobalClassFrom: SystemDictionary(Dictionary)>>at:ifAbsent: FLGlobalClassCluster(FLGlobalCluster)>>materializeGlobalClassFrom: FLGlobalClassCluster>>materializeFrom: FLGlobalClassCluster(FLPrimitiveCluster)>>materializeInstanceWith: [objects add: (self materializeInstanceWith: aMaterialization)] in FLGlobalClassCluster(FLIteratingCluster)>>materializeInstancesStepWith: SmallInteger(Integer)>>timesRepeat: FLGlobalClassCluster(FLIteratingCluster)>>materializeInstancesStepWith: FLMaterialization>>clusterInstancesStep [self clusterInstancesStep] in FLMaterialization>>instancesStep SmallInteger(Integer)>>timesRepeat: FLMaterialization>>instancesStep FLMaterialization>>run [:aStream | (FLMaterialization on: aStream) run; yourself] in FLMaterializer>>setDefaultMaterialization [self verifySignatureFrom: aStream. self verifyVersionFrom: aStream. ^ materializationFactory value: aStream] in FLMaterializer>>materializeFrom: BlockClosure>>ensure: FLMaterializer>>materializeFrom: [:aFileStream | self newDefault materializeFrom: aFileStream binary] in FLMaterializer class>>materializationFromFileNamed: [anotherBlock value: file] in StandardFileStream class(FileStream class)>>detectFile:do: BlockClosure>>ensure: StandardFileStream class(FileStream class)>>detectFile:do: StandardFileStream class(FileStream class)>>oldFileNamed:do: FLMaterializer class>>materializationFromFileNamed: UndefinedObject>>DoIt
Hi Yanni, On Fri, Nov 25, 2011 at 7:22 PM, Yanni Chiu <yanni@rogers.com> wrote:
On 25/11/11 3:56 PM, Yanni Chiu wrote:
Any ideas why Fuel is looking for OldClass, yet there are no instances of OldClass in the de-serialized object graph.
There are no instances, but the class object itself is being held in various places in the Pier kernel.
This can be the problem. Can you update these references to point NewClass? I want to support in fuel 1.8 some way of specifying that a class has been renamed. Something like: FLMaterializer newDefault classRenames: { #OldClass -> #NewClass } materializeFrom: aFile. Would this solve your problem? cheers, MartÃn
On 25/11/11 5:46 PM, Martin Dias wrote:
This can be the problem. Can you update these references to point NewClass?
Now that I know what's holding on to the class, I can figure out what to do. Ideally, I'd like to remove the reference to the class, and have the command list re-generated. This strategy is available for a Pier kernel, but not for the general migration problem for Fuel.
I want to support in fuel 1.8 some way of specifying that a class has been renamed. Something like:
FLMaterializer newDefault classRenames: { #OldClass -> #NewClass } materializeFrom: aFile.
Would this solve your problem?
Yes it would, but the real issue for me is whether or not the migration code stays forever in the code base, or should a one time migration step be run (and keep no migration trail in the Fuel code).
On 25/11/11 6:57 PM, Yanni Chiu wrote:
On 25/11/11 5:46 PM, Martin Dias wrote:
This can be the problem. Can you update these references to point NewClass?
Now that I know what's holding on to the class, I can figure out what to do. Ideally, I'd like to remove the reference to the class, and have the command list re-generated. This strategy is available for a Pier kernel, but not for the general migration problem for Fuel.
FYI, the solution was: 1) Define the old class so Fuel will load the kernel: Object subclass: #OldCommand instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'ZZZImportExport'. N.B. Subclass from Object, not PRCommand, because Pier looks for all subclasses of PRCommand. (This may not have been necessary, but was done just in case). 2) Change the reference from OldClass to NewClass PUSecurity allInstances do: [ :each | each otherPermissions do: [ :perm | perm command = OldCommand ifTrue: [ perm setCommand: NewCommand ] ]. each groupPermissions do: [ :perm | perm command = OldCommand ifTrue: [ perm setCommand: NewCommand ] ]. each ownerPermissions do: [ :perm | perm command = OldCommand ifTrue: [ perm setCommand: NewCommand ] ]. ]. 3) Re-serialize with Fuel 4) Remove the migration code
Well, this is clearly something we must improve and provide :) On Sun, Nov 27, 2011 at 12:23 AM, Yanni Chiu <yanni@rogers.com> wrote:
On 25/11/11 6:57 PM, Yanni Chiu wrote:
On 25/11/11 5:46 PM, Martin Dias wrote:
This can be the problem. Can you update these references to point NewClass?
Now that I know what's holding on to the class, I can figure out what to do. Ideally, I'd like to remove the reference to the class, and have the command list re-generated. This strategy is available for a Pier kernel, but not for the general migration problem for Fuel.
FYI, the solution was:
1) Define the old class so Fuel will load the kernel:
Object subclass: #OldCommand instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'ZZZImportExport'.
N.B. Subclass from Object, not PRCommand, because Pier looks for all subclasses of PRCommand. (This may not have been necessary, but was done just in case).
2) Change the reference from OldClass to NewClass
PUSecurity allInstances do: [ :each | each otherPermissions do: [ :perm | perm command = OldCommand ifTrue: [ perm setCommand: NewCommand ] ]. each groupPermissions do: [ :perm | perm command = OldCommand ifTrue: [ perm setCommand: NewCommand ] ]. each ownerPermissions do: [ :perm | perm command = OldCommand ifTrue: [ perm setCommand: NewCommand ] ]. ].
3) Re-serialize with Fuel
4) Remove the migration code
-- Mariano http://marianopeck.wordpress.com
I want to support in fuel 1.8 some way of specifying that a class has
been renamed. Something like:
FLMaterializer newDefault classRenames: { #OldClass -> #NewClass } materializeFrom: aFile.
Would this solve your problem?
Yes it would, but the real issue for me is whether or not the migration code stays forever in the code base, or should a one time migration step be run (and keep no migration trail in the Fuel code).
Sorry, I didn't understand your question/problem. THanks -- Mariano http://marianopeck.wordpress.com
On 27/11/11 8:35 AM, Mariano Martinez Peck wrote:
Sorry, I didn't understand your question/problem.
The class rename feature would have solved my loading problem easily. The problem I'm talking about is not a Fuel feature, but how to use Fuel. At this point, I did a one time migration, and then threw away the migration code. I was sure I could get the migration done, whether or not Fuel had the class rename feature. I was just wondering what to do about future migrations. I dislike having all these migration code fragments cluttering the code base. I think Fuel just needs to have features that support various migration strategies, but it doesn't have to say how the migration code is structured.
participants (3)
-
Mariano Martinez Peck -
Martin Dias -
Yanni Chiu