[Glass] Cleaning up TimeZone class history

[Dale Henrichs via Glass]

Oh, that's right, the instance that you created as SystemUser via 
default needs to be migrated as SystemUser ...

On 07/18/2016 12:33 PM, Paul DeBruicker via Glass wrote:
> 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.
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass