[Glass] Class Migration

[Dale Henrichs via Glass]

On 01/31/2016 10:24 PM, Otto Behrens via Glass wrote:
> Hello Dario,
>
> When your database is small, automatic migrations will be fine. But we 
> like to control when and how the migrations take place, because we 
> like to take the site down so that we do not have active users on the 
> system while migrations take place. I don't know how it's possible 
> anyway to be sure how your system will behave when migrations have run 
> partially (you then have the situation with some objects migrated and 
> others not: how will the system behave?)
>
> We often override the method #migrateFrom:instVarMap: to initialize 
> new instVars or to transform some instVars that have been renamed or 
> changed structure. What is important is that the you clean up these 
> methods after migration because it may cause harm if you migrate the 
> same class again. You can also write the migrateFrom:instVarMap: in a 
> way that it is idempotent, for example:
>
> migrateFrom: oldObject instVarMap: aMap
>   super migrateFrom: oldObject instVarMap: aMap.
>   someInstVar ifNil: [ someInstVar := OrderedCollection new ]
>
> We write this code in Pharo and put it in an extension package. This 
> code obviously only runs in GemStone.
>
> To invoke migrations, we have written a class that does the work, 
> similar to GsDeployer, which is what I think you can start with. If 
> you want to use some of the code we've written, you can just say.
Would it be possible for you to shre your variant of GsDeployer? It 
sounds like it has some useful functionality ...

Dale