[Glass] Cleaning up TimeZone class history

[Dale Henrichs via Glass]

On 07/17/2016 10:28 AM, Paul DeBruicker via Glass wrote:
> GLASS mailing list wrote
>> On an unrelated note ... Paul, do you realize that according to my mail
>> browser this reply arrived 20 minutes before the original email? Makes
>> it a bit interesting trying to read multiple emails on the same subject
>> since they are not really in "chronological order"... the other day each
>> message had a seemly random timestamp and the conversation was very
>> difficult to follow :)
> Thats probably a symptom of replying through the Nabble interface at
> forum.world.st rather than a regular ole mail client.  I'll see what I can
> do about it.  Just to confirm the frist message I wrote described attempting
> to use DataCurator and SystemUser, and the second just SystemUser with
> linked topaz.
I was thinking that perhaps your own clocks were acting up, but it seems 
that the forum.world.st clocks are out of sync ..
>
> GLASS mailing list wrote
>> What did the stack look like for the error?
>>
>> ... oh you are in a loop ... you need to explicitly abort before each
>> #migrateInstancesTo: call --- if there are modified objects in the
>> system. So a commit is probably needed after each #removeVersion: call
>> ... just a guess.
>>
>> Is there a reason why you are trying to clean up the class history for
>> Timezone?
>>
>> Dale
> Some of my domain objects store DateTimes and some of those DateTimes' time
> zones are now of the ObsoleteTimeZone2 class.  Reloading my packages after
> the upgrade installed my extensions on the TimeZone class and now the
> ObsoleteTimeZone2 class dnu a couple messages.  So I thought that by
> cleaning up the TimeZone class history all my DateTimes with the
> ObsoleteTimeZone2 class would be fixed up as well.
Ah okay now I see what you are trying to do ... There is no need to 
remove ObsoleteTimezone2 from the class history --- we added several new 
instance variables to TimeZone for 3.3.0 (I think) for performance 
reasons and our general approach is to avoid migrations during upgrades 
- In this case we have all of the standard methods implemented in 
ObsoleteTimezone2 and you would be none the wiser, if you hadn't 
extended the TimeZone class ...

You can either add your missing methods to ObsoleteTimeZone2 or migrate 
the instances. I've checked with the developer and it turns out that is 
safe to migrate the instances (if you want to pick up the optimizations 
send #initializeCache to each of the instances after migration) ... and 
you should be able to do the migration (sans class history modification) 
as DataCurator...
>
> I can also devise a strategy to just #become: all the DateTimes in my
> objects with ObsoleteTimeZone2 timezones.  Can't change the time zone in
> them directly because DateTimes are invariant.
There is a #migrateFrom:instVarMap: method in TimeZone, so doing a 
migration is the better alternative to using become:
>
> This is the first time its been an issue so I'm wondering if there is part
> of the installation guide I missed that covers things like this?  Or if it
> is indicative of a misstep in another part of my process.
>
I did a search of our docs[1] and didn't find anything, so I've 
submitted internal bug #46316 ... we should at minimum provide a bit of 
context in the release notes when we create Obsolete classes.

Dale

[1] https://cse.google.com/cse/home?cx=014580976650604809618:1cdoq5jo3te