[Glass] migrate problem
Locked
 
|
I have one class hierarchy that has between 40 and 50 Mio. instances. Now I needed to add an instVar to the root of the hierarchy. Doing it with gemtools I switched off auto migration and loaded the monticello package containing the changed. But now I have problems migrating the instances manually.
COEvent allSubclasses size gives 5 while COEvent classHistory first allSubclasses size gives 23. A COEvent classHistory first migrateTo: COEvent didn’t do the trick. And COEvent migrate gives me a MessageNotUnderstood occurred (error 2010), a Metaclass3 does not understand #’migrationDestination' I’m using GemStone version ‚3.1.0.2' Any hints, Norbert _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
|
|
And I forgot that the code is still using the old class version not the new one.
Norbert Am 16.01.2014 um 16:25 schrieb Norbert Hartl <[hidden email]>:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
|
|
In reply to this post by NorbertHartl
Norbert, I am not a migration expert and I haven't read the docs (yet), but in reading the code, I think that you are supposed to send the #migrate message to instances of your class ...
Have you looked at GsDeployer? I think the following will do a pretty good job of migrating the instances for you: GsDeployer bulkMigrate: ["add instance variable to class"]
in fact I think right now you should be able to do: GsDeployer bulkMigrate: ["empty block"] and get "pending migrations performed"....
Dale On Thu, Jan 16, 2014 at 7:25 AM, Norbert Hartl <[hidden email]> wrote:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
|
|
Dale,
that didn’t work. Now I have some of the classes doubled and some tripled. I need to try a few more things. I was just wondering that the migrateTo: does not work as expected. I did this a few times in the past and it always worked like that. Or I just can’t remember correctly. Norbert Am 16.01.2014 um 17:37 schrieb Dale Henrichs <[hidden email]>:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
|
|
Norbert,
I had the problem of 'double classes' in the past as well when I did loading via Monticello in gemtools rather than in topaz and using the GsDeployer. I retained the following script to fix that (which I believe was whipped up by Dale at that time) |classesWithOldSuperclasses| classesWithOldSuperclasses := Set new. Smalltalk allClasses do:[:s | Smalltalk allClasses do:[:c | (c superclass name = s name and:[(c superclass = s) not]) ifTrue:[classesWithOldSuperclasses add: c]]]. classesWithOldSuperclasses do:[:c | Transcript show: c name;cr. c definition evaluate] Hope it helps Johan On 16 Jan 2014, at 20:18, Norbert Hartl <[hidden email]> wrote: > Dale, > > that didn’t work. Now I have some of the classes doubled and some tripled. I need to try a few more things. I was just wondering that the migrateTo: does not work as expected. I did this a few times in the past and it always worked like that. Or I just can’t remember correctly. > > Norbert > > Am 16.01.2014 um 17:37 schrieb Dale Henrichs <[hidden email]>: > >> Norbert, >> >> I am not a migration expert and I haven't read the docs (yet), but in reading the code, I think that you are supposed to send the #migrate message to instances of your class ... >> >> Have you looked at GsDeployer? I think the following will do a pretty good job of migrating the instances for you: >> >> GsDeployer bulkMigrate: ["add instance variable to class"] >> >> in fact I think right now you should be able to do: >> >> GsDeployer bulkMigrate: ["empty block"] >> >> and get "pending migrations performed".... >> >> Dale >> >> >> On Thu, Jan 16, 2014 at 7:25 AM, Norbert Hartl <[hidden email]> wrote: >> I have one class hierarchy that has between 40 and 50 Mio. instances. Now I needed to add an instVar to the root of the hierarchy. Doing it with gemtools I switched off auto migration and loaded the monticello package containing the changed. But now I have problems migrating the instances manually. >> >> COEvent allSubclasses size >> >> gives 5 while >> >> COEvent classHistory first allSubclasses size >> >> gives 23. A >> >> COEvent classHistory first migrateTo: COEvent >> >> didn’t do the trick. And >> >> COEvent migrate >> >> gives me >> >> a MessageNotUnderstood occurred (error 2010), a Metaclass3 does not understand #’migrationDestination' >> >> I’m using >> >> GemStone version ‚3.1.0.2' >> >> Any hints, >> >> Norbert >> >> _______________________________________________ >> Glass mailing list >> [hidden email] >> http://lists.gemtalksystems.com/mailman/listinfo/glass >> >> > > _______________________________________________ > Glass mailing list > [hidden email] > http://lists.gemtalksystems.com/mailman/listinfo/glass _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
|
|
Norbert,
Given that you are searching for a solution, I thought I quickly write down how we deal with these things: I think #migrateTo: only configures the class for migration but does not execute it. When reviewing some of our past migration scripts, I notice I have always been using #migrateInstancesTo: But for any code change where no class names are changed (but other class migrations are necessary), I'm loading the new code in topaz using Metacello and launch the GsDeployer: MCPlatformSupport commitOnAlmostOutOfMemoryDuring: [ [ (Smalltalk at: #ConfigurationOfNextPlan) load. ] on: Warning do: [:ex | Transcript show: ex greaseString. ex resume]]. GsDeployer new doBulkMigrate. An important detail is that the Metacello configuration must be set to #atomic loading. If you leave it to the standard 'linear' loading, you might end up breaking a classhistory in the loading process, requiring you to manually add the new versions to the class history. This is because the linear loading might first load the package where the class was removed, hence removing the class definition from your system. When the other package that now contains the class is loaded afterwards, the monticello load does not detect is a new version of the old class. Since we use the above way of loading, we have only had to write manual migrations scripts when we do refactorings that move variables around in the class history such that the loading order becomes important. Johan On 16 Jan 2014, at 20:24, Johan Brichau <[hidden email]> wrote: > Norbert, > > I had the problem of 'double classes' in the past as well when I did loading via Monticello in gemtools rather than in topaz and using the GsDeployer. > I retained the following script to fix that (which I believe was whipped up by Dale at that time) > > |classesWithOldSuperclasses| > classesWithOldSuperclasses := Set new. > Smalltalk allClasses do:[:s | > Smalltalk allClasses do:[:c | > (c superclass name = s name and:[(c superclass = s) not]) ifTrue:[classesWithOldSuperclasses add: c]]]. > classesWithOldSuperclasses do:[:c | Transcript show: c name;cr. c definition evaluate] > > Hope it helps > Johan > > On 16 Jan 2014, at 20:18, Norbert Hartl <[hidden email]> wrote: > >> Dale, >> >> that didn’t work. Now I have some of the classes doubled and some tripled. I need to try a few more things. I was just wondering that the migrateTo: does not work as expected. I did this a few times in the past and it always worked like that. Or I just can’t remember correctly. >> >> Norbert >> >> Am 16.01.2014 um 17:37 schrieb Dale Henrichs <[hidden email]>: >> >>> Norbert, >>> >>> I am not a migration expert and I haven't read the docs (yet), but in reading the code, I think that you are supposed to send the #migrate message to instances of your class ... >>> >>> Have you looked at GsDeployer? I think the following will do a pretty good job of migrating the instances for you: >>> >>> GsDeployer bulkMigrate: ["add instance variable to class"] >>> >>> in fact I think right now you should be able to do: >>> >>> GsDeployer bulkMigrate: ["empty block"] >>> >>> and get "pending migrations performed".... >>> >>> Dale >>> >>> >>> On Thu, Jan 16, 2014 at 7:25 AM, Norbert Hartl <[hidden email]> wrote: >>> I have one class hierarchy that has between 40 and 50 Mio. instances. Now I needed to add an instVar to the root of the hierarchy. Doing it with gemtools I switched off auto migration and loaded the monticello package containing the changed. But now I have problems migrating the instances manually. >>> >>> COEvent allSubclasses size >>> >>> gives 5 while >>> >>> COEvent classHistory first allSubclasses size >>> >>> gives 23. A >>> >>> COEvent classHistory first migrateTo: COEvent >>> >>> didn’t do the trick. And >>> >>> COEvent migrate >>> >>> gives me >>> >>> a MessageNotUnderstood occurred (error 2010), a Metaclass3 does not understand #’migrationDestination' >>> >>> I’m using >>> >>> GemStone version ‚3.1.0.2' >>> >>> Any hints, >>> >>> Norbert >>> >>> _______________________________________________ >>> Glass mailing list >>> [hidden email] >>> http://lists.gemtalksystems.com/mailman/listinfo/glass >>> >>> >> >> _______________________________________________ >> Glass mailing list >> [hidden email] >> http://lists.gemtalksystems.com/mailman/listinfo/glass > _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
|
|
In reply to this post by Johan Brichau-3
Johan,
thank you very much for your help. Am 16.01.2014 um 20:24 schrieb Johan Brichau <[hidden email]>: > Norbert, > > I had the problem of 'double classes' in the past as well when I did loading via Monticello in gemtools rather than in topaz and using the GsDeployer. > I retained the following script to fix that (which I believe was whipped up by Dale at that time) > > |classesWithOldSuperclasses| > classesWithOldSuperclasses := Set new. > Smalltalk allClasses do:[:s | > Smalltalk allClasses do:[:c | > (c superclass name = s name and:[(c superclass = s) not]) ifTrue:[classesWithOldSuperclasses add: c]]]. > classesWithOldSuperclasses do:[:c | Transcript show: c name;cr. c definition evaluate] > Now I’m just wondering why the mark for collect only marked a little more than 300.000 objects to be removed while I think I removed approx. 40 million. The adventures continues. thanks, Norbert > Hope it helps > Johan > > On 16 Jan 2014, at 20:18, Norbert Hartl <[hidden email]> wrote: > >> Dale, >> >> that didn’t work. Now I have some of the classes doubled and some tripled. I need to try a few more things. I was just wondering that the migrateTo: does not work as expected. I did this a few times in the past and it always worked like that. Or I just can’t remember correctly. >> >> Norbert >> >> Am 16.01.2014 um 17:37 schrieb Dale Henrichs <[hidden email]>: >> >>> Norbert, >>> >>> I am not a migration expert and I haven't read the docs (yet), but in reading the code, I think that you are supposed to send the #migrate message to instances of your class ... >>> >>> Have you looked at GsDeployer? I think the following will do a pretty good job of migrating the instances for you: >>> >>> GsDeployer bulkMigrate: ["add instance variable to class"] >>> >>> in fact I think right now you should be able to do: >>> >>> GsDeployer bulkMigrate: ["empty block"] >>> >>> and get "pending migrations performed".... >>> >>> Dale >>> >>> >>> On Thu, Jan 16, 2014 at 7:25 AM, Norbert Hartl <[hidden email]> wrote: >>> I have one class hierarchy that has between 40 and 50 Mio. instances. Now I needed to add an instVar to the root of the hierarchy. Doing it with gemtools I switched off auto migration and loaded the monticello package containing the changed. But now I have problems migrating the instances manually. >>> >>> COEvent allSubclasses size >>> >>> gives 5 while >>> >>> COEvent classHistory first allSubclasses size >>> >>> gives 23. A >>> >>> COEvent classHistory first migrateTo: COEvent >>> >>> didn’t do the trick. And >>> >>> COEvent migrate >>> >>> gives me >>> >>> a MessageNotUnderstood occurred (error 2010), a Metaclass3 does not understand #’migrationDestination' >>> >>> I’m using >>> >>> GemStone version ‚3.1.0.2' >>> >>> Any hints, >>> >>> Norbert >>> >>> _______________________________________________ >>> Glass mailing list >>> [hidden email] >>> http://lists.gemtalksystems.com/mailman/listinfo/glass >>> >>> >> >> _______________________________________________ >> Glass mailing list >> [hidden email] >> http://lists.gemtalksystems.com/mailman/listinfo/glass > _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
|
|
Is your Object Log clean? Continuations in your Object Log can hold onto rafts of objects ... to make matters worse I mispelled the initialize method --> ObjectLogEntry class>>initalize Dale On Thu, Jan 16, 2014 at 1:07 PM, Norbert Hartl <[hidden email]> wrote: Johan, _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
«
Return to GLASS
|
1 view|%1 views
| Free forum by Nabble | Edit this page |