[Glass] About GsDeployer new doBulkMigrate

[Mariano Martinez Peck]

On Wed, Apr 16, 2014 at 7:38 PM, Dale Henrichs <
dale.henrichs at gemtalksystems.com> wrote:

> Mariano,
>
> You are correct, but once you've migrated all of your instances forward,
> you don't need the classes in your class history ...
>
>
Yes.


> The other thing to watch for when doing bulk migrations is executing code
> during the load that might REQUIRE all instances to be migrated ... the
> migrations are not done until the end of the load  ... the classic example
> is Monticell itself ... back when I was actively finding and fixing bugs in
> the Monticello loaders the new methods were being sent to old instances so
> i _had_ to migrate during the load ...
>
>
And how did you do that? (migrate during load)


> As a final comment ... if for some reason you mess up your class history,
> it should be possible to rebuild the class history from the instances of
> the old class ... while it is something you don't want to do ... it's worth
> keeping in mind that it can be done in an emergency:)
>
>
Ahhhh of course...the migrate stuff "just" changes the class pointer of the
instances right? So if the slots for XXX instVars were there...they won't
get lost. I guess it is similar to Pharo's #adoptInstance: and
#primitiveChangeClassTo:
Good!


> Dale
>
>
> On Wed, Apr 16, 2014 at 12:05 PM, Mariano Martinez Peck <
> marianopeck at gmail.com> wrote:
>
>> Hi gemstoners,
>>
>> I have just finished reading "Chapter 10 - Class Creation, Versions, and
>> Instance Migration" but when I was about to start writing some scripts I
>> found GsDeployer. I found this very interesting expression: "GsDeployer new
>> doBulkMigrate".
>>
>> I am not 100% sure of what it does, so please confirm if I understand
>> correctly:
>>
>> 1) it searches each class of symbol list of current user that has more
>> than 1 in the class history
>> 2) it migrates each version of each found class to the last one from the
>> history. And this migration is the basic ones... I mean, new instVars in
>> new class will be with nil, and old instVars not existing in new class will
>> be dropped, etc.
>> 3) committs etc..
>>
>> So...is that correct? If true, then it means that if I don't have any
>> specific migration matter (like instVar renaming, or initialize some new
>> instvar with some state that depends on old value, etc etc etc), that would
>> migrate everything automatically, right?
>>
>> But...if that's correct...I need to be *very very very* careful in
>> executing such a migration since after the migration I will have lost all
>> previous class versions and more importantly, I will have lost instVars
>> from old classes in the case new class does not define them. Correct?
>>
>> Thanks in advance,
>>
>> --
>> Mariano
>> http://marianopeck.wordpress.com
>>
>> _______________________________________________
>> Glass mailing list
>> Glass at lists.gemtalksystems.com
>> http://lists.gemtalksystems.com/mailman/listinfo/glass
>>
>>
>


-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20140416/16c7c789/attachment.html>