Loading a class definition from a package is skipped if superclass is in the class history of the actual superclass (during upgrade) #77
Comments
dalehenrich
added a commit
to glassdb/glass
that referenced
this issue
Sep 15, 2015
…) to reproduce the bug
dalehenrich
added a commit
to glassdb/glass
that referenced
this issue
Sep 16, 2015
…low MCPackageLoader>>equalDefinition:to: to make a last second comparison of the new defintion against the actual state of the image when loading ... and we can catch the version history superclass difference and schedule the definition for loading
dalehenrich
added a commit
to glassdb/glass
that referenced
this issue
Sep 16, 2015
…om the MCEquality patch operations ...
dalehenrich
added a commit
to dalehenrich/tode
that referenced
this issue
Sep 16, 2015
dalehenrich
added a commit
to glassdb/glass
that referenced
this issue
Sep 16, 2015
Merged
dalehenrich
added a commit
to glassdb/glass
that referenced
this issue
Apr 10, 2023
…tone uses a baseline project to load Zodiac and Pharo does not ... add SSL group for loading SSL support on pharo or GemStone
dalehenrich
added a commit
to glassdb/glass
that referenced
this issue
Apr 10, 2023
…d to pass at the moment
dalehenrich
added a commit
to glassdb/glass
that referenced
this issue
Apr 10, 2023
… fiddle baseline. Update ZnHTTPSTests>>testGForceInria and and adjust ZnHTTPSTests for GemStone
dalehenrich
added a commit
to glassdb/glass
that referenced
this issue
Apr 10, 2023
… in server structure (svenvc/zinc#17)
dalehenrich
added a commit
to glassdb/glass
that referenced
this issue
Apr 10, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
If everything else is equal referencing loading a class definition when the superclass is an old version of the class, should cause a new version of the class to be created and thus linking the class up with the new superclass and possibly triggering migrations ...
It is kinda hard to get into this situation in a normal environment but upgrading to a system where class versions get introduced can expose the problem.
The root cause of the problem is that
MCPatch>>initializeWithBase:target:callsMCDefinition>>isSameRevisionAs:which ends up doing an equality test that uses the name of the superclass ...MCClassDefinition>>hasSimpleModsRelativeTo:has the proper test for superclass ...The text was updated successfully, but these errors were encountered: