Cleaning up TimeZone class history

GLASS mailing list wrote

Hi -

In my stone I have ObsoleteTimeZone & ObsoleteTimeZone2 in the TimeZone class history of a stone I just updated to 3.3.1.   The DataCurator user doesn't have permissions to migrate those classes apparently.  And when I sign in as the SystemUser in linked Topaz the Smalltalk symbol is not understood.  

To do the migration I'm running:

  System abort.
  System beginTransaction.
  [ :className |
  | c |
  c := Smalltalk at: className.
  c isBehavior
    ifTrue: [
      [ c classHistory size > 1 ]
        whileTrue: [
          (c classHistory at: 1) migrateInstancesTo: c classHistory currentVersion.
          c classHistory removeVersion: (c classHistory at: 1) ] ] ]
    value: #'TimeZone'.
  System commitTransaction



Thanks


Paul
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

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

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

GLASS mailing list wrote

On 7/16/16 4:24 PM, Paul DeBruicker via Glass wrote:
> Oh and if logged in as SystemUser in linked topaz I run
>
> topaz 1> abort
> topaz 1> printit
>    [ TimeZone classHistory size > 1 ]
>      whileTrue: [
>        (TimeZone classHistory at: 1)
>          migrateInstancesTo: TimeZone classHistory currentVersion.
>        TimeZone classHistory removeVersion: (TimeZone classHistory at: 1) ].
> %
>
> I get this error:
>
>
> ERROR 2412 , a TransactionError occurred (error 2412),
> reason:rtErrAbortWouldLoseData, A method that requires an abort is being
> executed, however, an abort would result in lost data. (TransactionError)
>
>
> So progress, but not completely there.
>
>
>
>
>
> GLASS mailing list wrote
>> Hi -
>>
>> In my stone I have ObsoleteTimeZone & ObsoleteTimeZone2 in the TimeZone
>> class history of a stone I just updated to 3.3.1.   The DataCurator user
>> doesn't have permissions to migrate those classes apparently.  And when I
>> sign in as the SystemUser in linked Topaz the Smalltalk symbol is not
>> understood.
>>
>> To do the migration I'm running:
>>
>>    System abort.
>>    System beginTransaction.
>>    [ :className |
>>    | c |
>>    c := Smalltalk at: className.
>>    c isBehavior
>>      ifTrue: [
>>        [ c classHistory size > 1 ]
>>          whileTrue: [
>>            (c classHistory at: 1) migrateInstancesTo: c classHistory
>> currentVersion.
>>            c classHistory removeVersion: (c classHistory at: 1) ] ] ]
>>      value: #'TimeZone'.
>>    System commitTransaction
>>
>>
>>
>> Thanks
>>
>>
>> Paul
>> _______________________________________________
>> Glass mailing list
>> Glass@.gemtalksystems
>> http://lists.gemtalksystems.com/mailman/listinfo/glass
>
>
>
>
> --
> View this message in context: http://forum.world.st/Cleaning-up-TimeZone-class-history-tp4906795p4906796.html
> Sent from the GLASS mailing list archive at Nabble.com.
> _______________________________________________
> Glass mailing list
> [hidden email]
> http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

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
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass