[Glass] Cleaning up TimeZone class history
Dale Henrichs via Glass
glass at lists.gemtalksystems.com
Mon Jul 18 11:19:25 PDT 2016
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
> 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)
> 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 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.
More information about the Glass