[Glass] Class Migration

[Trussardi Dario Romano via Glass]

Ciao Otto,

	thanks for your considerations.

> 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:
> 

	What you intend?

	This is not the default	implementation of:	 migrateFrom: oldObject instVarMap: aMap

> 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.

O yes i'm very interested.

I read and test the GsDeployer support on GLASS 3.1.0.6.  it's very interesting based.

Now i need to understand and work for implement a support to integrate it with Pharo development.

I think your experience is very good and if you can share your works, i can start with some value added.

Thanks,

	Dario

> There are several other issues to deal with when the system becomes complex, some are:
> - Fixing data problems before doing the migration
> - Renaming classes
> - Controlling the order of migrating some classes before others
> - Ensuring that all instances are migrated when you're done
> 
> Let me know if this helps or if you need more information.
> 
> Cheers
> Otto
> 
> On Sat, Jan 30, 2016 at 5:24 PM, Trussardi Dario Romano via Glass <glass at lists.gemtalksystems.com> wrote:
> Ciao,
> 
> 	i need to manage the 'migrations' of class and relative instances.
> 
> 	I read the Prog-guide3-1	Class Creation, Versions, and Instance Migration .
> 
> 
> 	Now my question is how to manage the migration when i development in Pharo,
> 
> 	 and load the new structure into GLASS with the relative package using GemTools or Tode.
> 
> 	I do some test with GemTools migrate option and filetree packages load.
> 
> 
> 
> 	Question:
> 
> 		someone implemented a support into Pharo to handle these problematic
> 
> 		and porting the 'migration' into Gemstone?
> 
> 	
> 	I think of something that when I change classes in Pharo,   
> 
> 	record - define  the statements that then allow gemstone to applying migration.
> 
> 
> 	Thanks for any considerations,
> 
> 		Dario
> 
> 
> 
> 
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20160201/4254ea94/attachment.html>