Hey,
I would like to know, how migration of instances to new class versions is actually automatically triggered - in case * when I import a Monticello package or * when I import source code via topaz. I've seen something like "MCPlatformSupport autoMigrate: true" - but how does it work ? Thanks, Marten -- Marten Feldtmann _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Marten,
If MCPlatformSupport class>>autoMigrate is true, then automatic migration of instances is performed for each of the classes modified ... the migrations are performed after the shape of the class is changed, so there can be several migrations sweeps if you are changing a superclass ... You can use GsDeployer class>>bulkMigrate: to defer instance migration until the block is finished, which means that you'll make one pass to migrate instances of all of the classes changed during the execution of the block ... For most cases I recommend that you wrap all of your loads with this expression to save on migration costs ... By default, MCPlatformSupport class>>autoMigrate is off ... so when you do things in topaz, automatic migration is not turned on ... one of the reasons I recommend that GsDeployer class>>bulkMigrate: for all loads ... In GemTools automatic migration is turned on at login time. Not sure what happens in Jade. Questions? Dale On 05/21/2015 12:55 PM, [hidden email] via Glass wrote: > Hey, > > I would like to know, how migration of instances to new class versions > is actually automatically triggered - in case > > * when I import a Monticello package > > or > > * when I import source code via topaz. > > I've seen something like "MCPlatformSupport autoMigrate: true" - but how > does it work ? > > > Thanks, > > Marten > > _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Hello Dale,
that means, * that MCPlatformSupport class>>autoMigrate also works for topaz imported code ? But then: how do I add a method like "migrateFrom: oldPoint instVarMap: aMap" which is oriented towards the "new" class design - but can only compiled when the new class definition is available. But when the new class definition is recognized (during import) the migration is started - but then the method mentioned above is not available yet. Therefore it seems for me, that when importing pure-source code via topaz I have to switch off auto migration and manually add source code to do migration after ALL source code has been imported ... Or I use doit GsDeployer bulkMigrate: [ /* creation code for new class shape definitions */ PUMGeneralDomainObject subclass: 'CATIEnumAddressState' instVarNames: #( ) classVars: #( ) classInstVars: #( ) poolDictionaries: #( ) inDictionary: 'UserGlobals' category: 'GessCATIProject' options: #( ). and further class definitions .. /* in addition all codes needed for migration - not possible !? */ ]. % but in this example I can not add source code for methods ... therefore doing it manually seems to be the only way ... Marten Am 22.05.2015 um 02:58 schrieb Dale Henrichs via Glass: > Marten, > > If MCPlatformSupport class>>autoMigrate is true, then automatic > migration of instances is performed for each of the classes modified ... > the migrations are performed after the shape of the class is changed, so > there can be several migrations sweeps if you are changing a superclass ... > > You can use GsDeployer class>>bulkMigrate: to defer instance migration > until the block is finished, which means that you'll make one pass to > migrate instances of all of the classes changed during the execution of > the block ... For most cases I recommend that you wrap all of your loads > with this expression to save on migration costs ... > > By default, MCPlatformSupport class>>autoMigrate is off ... so when you > do things in topaz, automatic migration is not turned on ... one of the > reasons I recommend that GsDeployer class>>bulkMigrate: for all loads ... > > In GemTools automatic migration is turned on at login time. Not sure > what happens in Jade. > > Questions? > > Dale > > On 05/21/2015 12:55 PM, [hidden email] via Glass wrote: >> Hey, >> >> I would like to know, how migration of instances to new class versions >> is actually automatically triggered - in case >> >> * when I import a Monticello package >> >> or >> >> * when I import source code via topaz. >> >> I've seen something like "MCPlatformSupport autoMigrate: true" - but how >> does it work ? >> >> >> Thanks, >> >> Marten >> >> > > _______________________________________________ > Glass mailing list > [hidden email] > http://lists.gemtalksystems.com/mailman/listinfo/glass -- Marten Feldtmann _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
In reply to this post by GLASS mailing list
Hello Dale,
that means, * that MCPlatformSupport class>>autoMigrate also works for topaz imported code ? But then: how do I add a method like "migrateFrom: oldPoint instVarMap: aMap" which is oriented towards the "new" class design - but can only compiled when the new class definition is available. But when the new class definition is recognized (during import) the migration is started - but then the method mentioned above is not available yet. Therefore it seems for me, that when importing pure-source code via topaz I have to switch off auto migration and manually add source code to do migration after ALL source code has been imported ... Or I use doit GsDeployer bulkMigrate: [ /* creation code for new class shape definitions */ PUMGeneralDomainObject subclass: 'CATIEnumAddressState' instVarNames: #( ) classVars: #( ) classInstVars: #( ) poolDictionaries: #( ) inDictionary: 'UserGlobals' category: 'GessCATIProject' options: #( ). and further class definitions .. /* in addition all codes needed for migration - not possible !? */ ]. % but in this example I can not add source code for methods ... therefore doing it manually seems to be the only way ... Marten Am 22.05.2015 um 02:58 schrieb Dale Henrichs via Glass: > Marten, > > If MCPlatformSupport class>>autoMigrate is true, then automatic > migration of instances is performed for each of the classes modified ... > the migrations are performed after the shape of the class is changed, so > there can be several migrations sweeps if you are changing a superclass ... > > You can use GsDeployer class>>bulkMigrate: to defer instance migration > until the block is finished, which means that you'll make one pass to > migrate instances of all of the classes changed during the execution of > the block ... For most cases I recommend that you wrap all of your loads > with this expression to save on migration costs ... > > By default, MCPlatformSupport class>>autoMigrate is off ... so when you > do things in topaz, automatic migration is not turned on ... one of the > reasons I recommend that GsDeployer class>>bulkMigrate: for all loads ... > > In GemTools automatic migration is turned on at login time. Not sure > what happens in Jade. > > Questions? > > Dale > > On 05/21/2015 12:55 PM, [hidden email] via Glass wrote: >> Hey, >> >> I would like to know, how migration of instances to new class versions >> is actually automatically triggered - in case >> >> * when I import a Monticello package >> >> or >> >> * when I import source code via topaz. >> >> I've seen something like "MCPlatformSupport autoMigrate: true" - but how >> does it work ? >> >> >> Thanks, >> >> Marten >> >> > > _______________________________________________ > Glass mailing list > [hidden email] > http://lists.gemtalksystems.com/mailman/listinfo/glass -- Marten Feldtmann _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
In reply to this post by GLASS mailing list
manually this could be done via the following code - I assume (without
considering out of memory problems or stuff like this): /* here is code to import my new class definitions and methods */ /* then a commit is done */ /* a new transaction is started */ allMyClasses do: [ :eachClass | | classHistory | (classHistory := eachClass classHistory) isNil ifFalse:[ "the last element seems to be the current class" 1 to: (classHistory size -1) do: [ :anIndex | (classHistory at: anIndex) migrateInstancesTo: eachClass ]. ]. ]. /* and again a commit */ Marten -- Marten Feldtmann _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
In reply to this post by GLASS mailing list
On 05/21/2015 10:22 PM, [hidden email] via Glass wrote: > Hello Dale, > > that means, > > * that MCPlatformSupport class>>autoMigrate also works for topaz > imported code ? > > But then: how do I add a method like "migrateFrom: oldPoint instVarMap: > aMap" which is oriented towards the "new" class design - but can only > compiled when the new class definition is available. to turn off autoMigrate during your load and add arrange to migrate the instances yourself ... you can get inspiration from the code in GsDeployer.... > > But when the new class definition is recognized (during import) the > migration is started - but then the method mentioned above is not > available yet. Right, the autoMigrate option is to make the GLASS/GsDevKit environment more like a traditional Smalltalk dev environment where class migration is not something you have to worry about ... for a db that may have billions of objects, automatic migration is not practical .. > > Therefore it seems for me, that when importing pure-source code via > topaz I have to switch off auto migration and manually add source code > to do migration after ALL source code has been imported ... > > Or I use > > doit > GsDeployer bulkMigrate: [ > > /* creation code for new class shape definitions */ > > PUMGeneralDomainObject subclass: 'CATIEnumAddressState' > instVarNames: #( ) > classVars: #( ) > classInstVars: #( ) > poolDictionaries: #( ) > inDictionary: 'UserGlobals' > category: 'GessCATIProject' > options: #( ). > > and further class definitions .. > > /* in addition all codes needed for migration - not possible !? */ > > ]. > % > > but in this example I can not add source code for methods ... therefore > doing it manually seems to be the only way ... The bulkMigrate: method only makes the automatic migration a bit more efficient ... When you have a custom migration to do, then you can look at the code in GsDeployer and modify it to meet your specific needs ... and if you happen to come across a useful extension to GsDeployer for handling your custom migrations, you could share your code with the community:) Dale _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
In reply to this post by GLASS mailing list
Marten,
That's basically it... Dale On 05/21/2015 10:43 PM, [hidden email] via Glass wrote: > manually this could be done via the following code - I assume (without > considering out of memory problems or stuff like this): > > > /* here is code to import my new class definitions and methods */ > > /* then a commit is done */ > > /* a new transaction is started */ > > allMyClasses do: [ :eachClass | > | classHistory | > > (classHistory := eachClass classHistory) isNil ifFalse:[ > "the last element seems to be the current class" > 1 to: (classHistory size -1) do: [ :anIndex | > (classHistory at: anIndex) migrateInstancesTo: eachClass > ]. > ]. > ]. > > /* and again a commit */ > > Marten > _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Free forum by Nabble | Edit this page |