[Glass] error upgrading stone: become is not allowed
Dale Henrichs via Glass
glass at lists.gemtalksystems.com
Thu Apr 27 10:57:15 PDT 2017
On 04/27/2017 08:22 AM, Johan Brichau via Glass 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?
I guess to start with, I'd like to see more of the stack ... for some
reason you are apparently getting a new class version of
NPGsFileWrapper... there is a fair amount of logic in McClassDefinition
(MCClassDefinition>>hasSimpleModsRelativeTo:) and the class creation
code
(Class>>_equivalentSubclass:superCls:name:newOpts:newFormat:newInstVars:newClassInstVars:newPools:newClassVars:inDict:constraints:isKernel:)that
attempts to avoid creating new versions of a class unless "absolutely
necessary."
So the first thing to explore is why you are migrating the class when no
class versions should have been created --- assuming that the shape of
the class NPGsFileWrapper hasn't changed ...
I am also curious what steps you've done to do the upgrade prior to
loading. Ideally you would be doing something very similar to what is
done by the GsDevKit_home upgradeStone script[1] ...
Dale
[1] https://github.com/GsDevKit/GsDevKit_home/blob/master/bin/upgradeStone
> Or do we need to move away from having instances of classes that are subclasses of GsFile before we attempt to upgrade?
>
> thx
> Johan
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass
More information about the Glass
mailing list