[Glass] Cleaning up TimeZone class history

[Paul DeBruicker via Glass]

Thanks Dale.

I went ahead and migrated the instances.   It did seem to require using
SystemUser to migrate the UTC timezone.  I assume because its the one I've
installed as default/current.  



Paul



GLASS mailing list wrote
> 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
> _______________________________________________
> Glass mailing list

> Glass at .gemtalksystems

> http://lists.gemtalksystems.com/mailman/listinfo/glass





--
View this message in context: http://forum.world.st/Cleaning-up-TimeZone-class-history-tp4906795p4907018.html
Sent from the GLASS mailing list archive at Nabble.com.