Cleaning up TimeZone class history

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Cleaning up TimeZone class history

GLASS mailing list
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
Reply | Threaded
Open this post in threaded view
|

Re: Cleaning up TimeZone class history

Paul DeBruicker
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
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: Cleaning up TimeZone class history

GLASS mailing list
In reply to this post by GLASS mailing list
Paul,

The class histories for base classes is (usually) intentional ... There
are about a half dozen base classes that have class histories and I
don't think it's necessary to clean up their class history ... most of
the class histories are there to support upgrades, but IIRC one or two
of them are there to support useful functionality (i.e., MultiByteString
is in the class history of String so that #isKindOf: 'works') ...

Dale

On 7/16/16 4:49 PM, PAUL DEBRUICKER via Glass 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
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: Cleaning up TimeZone class history

GLASS mailing list
In reply to this post by Paul DeBruicker
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 :)

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

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
Reply | Threaded
Open this post in threaded view
|

Re: Cleaning up TimeZone class history

Paul DeBruicker
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.

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.  

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.  

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.




Anyway thanks for getting back to me on a Sunday.  


Paul



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
Reply | Threaded
Open this post in threaded view
|

Re: Cleaning up TimeZone class history

GLASS mailing list


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
Reply | Threaded
Open this post in threaded view
|

Re: Cleaning up TimeZone class history

Paul DeBruicker
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
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: Cleaning up TimeZone class history

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

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