[Glass] Class Migration

[Otto Behrens via Glass]

Sorry, did not attach the package in the previous mail.

On Mon, Feb 1, 2016 at 2:52 PM, Otto Behrens <otto at finworks.biz> wrote:

> 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
>>
>
> When you migrate objects where you changed the instVars and you want to do
> something special with each object (like initializing the new instVar as in
> the example I gave you below), in this case, you override
> migrateFrom:instVarMap:
>
>
>> migrateFrom: oldObject instVarMap: aMap
>>   super migrateFrom: oldObject instVarMap: aMap.
>>   someInstVar ifNil: [ someInstVar := OrderedCollection new ]
>>
>>
>> O yes i'm very interested.
>>
>
> I attach a package that I extracted from our code (into a new package).
> You can load this package and call
>
> Migrator new packageNames: #(); migrateAll
>
>
>> Now i need to understand and work for implement a support to integrate it
>> with Pharo development.
>>
>
> You can load this same package in Pharo. But, there are some classes like
> System that you need defined. GemStone has a "Grease" package that you can
> load in Pharo. I do not know what is its name. We just have our own package
> where we define classes such as System and Metaclass3. And this package we
> only load in Pharo as this Migrator code will never run in Pharo.
>
>
>> I think your experience is very good and if you can share your works, i
>> can start with some value added.
>>
>
> Hope this helps. Let me know where are some gaps.
>
>
>>
>> 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 m
>>> igration.
>>>
>>>
>>> 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/de21af51/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Wonka-Migrations-Core-otto.12.mcz
Type: application/octet-stream
Size: 10627 bytes
Desc: not available
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20160201/de21af51/attachment-0001.obj>