[Glass] About GsDeployer new doBulkMigrate

[Dale Henrichs]

On Wed, Apr 16, 2014 at 4:31 PM, Mariano Martinez Peck <
marianopeck at gmail.com> wrote:

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

Are you sure that you want to know? ... haha ... actually over the lifetime
of GLASS I've attempted all sorts of hacks installing missing methods as
part of preload, putting in error handlers in the new code to do the right
thing, and crossing my fingers:)

Probably the toughest problem is that GemStone does not allow you to
migrate instances that are on the _active_ stack ... after trying lots of
different things, I finally settled on a technique where we used a forked
thread to do the migrate for instances on the stack. While the forked code
is active, the load stack is inactive and migration can occur ...

You can take a look at the load method in the monticello package loader if
you want to see  the level of hackery that has been employed:)

>
>
>> 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/27d4d329/attachment.html>