[Glass] error upgrading stone: become is not allowed

[Johan Brichau via Glass]

Final info: when I remove the instance before starting the upgrade process, all works fine.
As the instance was only persistent because it was on the object log, I don’t need to try to keep it.

> On 27 Apr 2017, at 17:48, Johan Brichau <johan at yesplan.be> wrote:
> 
> A bit more info… I did a lookup of the oops mentioned in the call of become:
> 
> In the source 2.4 extent:
> 	The receiver object with oop 4489369089 does not exist
> 	The argument object with oop 148062465 is an instance of NPGsFileWrapper
> 
> In the destination 3.2 extent (following the failed bulk migrate after application load):
> 	The receiver object with oop 4489369089 is an object anArray( #'switch')
> 	The argument object with oop 148062465 is still that instance of NPGsFileWrapper
> 
> When I executed: SystemRepository findReferencePathToObject: (Object _objectForOop: 4489369089), I got:
> a ArgumentError occurred (error 2027), A committed object was expected rather than object anArray( #'switch'), which is either special or uncommitted.
> 
>> On 27 Apr 2017, at 17:22, Johan Brichau <johan at yesplan.be> wrote:
>> 
>> Hi,
>> 
>> In the conversion of a Gemstone 2.4.4.1 stone to Gemstone 3.2, I hit an error in the final step when loading our application code:
>> 
>> a ImproperOperation occurred (error 2426), become is not allowed on aNPGsFileWrapper, 'One object is a GsFile or RubySocket while the other is neither'
>> Error Category: 231169 [GemStone] Number: 2426  Arg Count: 2 Context : 1906733569 exception : 4489410561
>> 
>> We indeed have a subclass of GsFile, called NPGsFileWrapper
>> Migrating the instances on application load seems to wrong, though both the old and new class are ‘NPGsFileWrapper’ (see stack context of the invocation of become: below)
>> 
>> 5 NPGsFileWrapper (Object) >> become:           @4 line 112   [methId 59070977]
>>   receiver [4489369089 sz:6 cls: 4487621633 NPGsFileWrapper] aNPGsFileWrapper
>>   anObject [148062465 sz:4 cls: 6802930945 NPGsFileWrapper] aNPGsFileWrapper
>>   self [4489369089 sz:6 cls: 4487621633 NPGsFileWrapper] aNPGsFileWrapper
>>   prot [10 sz:0 cls: 74241 SmallInteger] 1 == 0x1
>> 
>> Any way to circumvent this issue in the upgrade?
>> Or do we need to move away from having instances of classes that are subclasses of GsFile before we attempt to upgrade?
>> 
>> thx
>> Johan
>