Hi,
in my newly started project I came to a point where I decided that I don't want to loose data anymore. So I needed to learn something about migration of classes and objects. I'm not really sure if my workflow is a desired one or just awkward. I had a class where I accidenitally assigned a class instance var but it should be a class var just. In this classes I have a instance variable instances that holds all instances of this class. Updating the model that changes the vars always led to having all instances lost. So with a few trials I did the following: - turned off auto commit and auto migrate - copied all instances from the class to UserGlobals - loaded the code with monticello - copied all instances from UserGlobals to the instance var in the class again - committed the transaction - I checked that the old version of the class was position 4 in the class history and the new one 5 - just did (HRWine classHistory at: 4) migrateInstancesTo: (HRWine classHistory at: 5) Is this the way to go or did I miss some things. I read the programmers guide about migration but did not find the exact information how to do this. any hints welcomed, Norbert |
I believe that James is traveling today (and or tomorrow), but he has been working on solutions in this area, so I will give him a chance to reply ...
Dale ----- "Norbert Hartl" <[hidden email]> wrote: | Hi, | | in my newly started project I came to a point where I decided that I | don't want to loose data anymore. So I needed to learn something about | migration of classes and objects. I'm not really sure if my workflow | is a desired one or just awkward. | | I had a class where I accidenitally assigned a class instance var but | it should be a class var just. In this classes I have a instance | variable instances that holds all instances of this class. Updating | the model that changes the vars always led to having all instances | lost. So with a few trials I did the following: | | - turned off auto commit and auto migrate | - copied all instances from the class to UserGlobals | - loaded the code with monticello | - copied all instances from UserGlobals to the instance var in the | class again | - committed the transaction | - I checked that the old version of the class was position 4 in the | class history and the new one 5 | - just did (HRWine classHistory at: 4) migrateInstancesTo: (HRWine | classHistory at: 5) | | Is this the way to go or did I miss some things. I read the | programmers guide about migration but did not find the exact | information how to do this. | | any hints welcomed, | | Norbert |
In reply to this post by NorbertHartl
Norbert,
Your approach (described below) is a very good approach. Given that the old class is still available as #4 in the classHistory, you could have avoided the intermediate storage in UserGlobals, but the intermediate step probably simplified things. As Dale mentions elsewhere, I am working on a migration strategy, but it assumes that class variables and class instance variables are consistent between versions. If there are to be changes in the class-side schema (as you have done), then some specific handling would be required and something analogous to your approach would have been needed. Because of the (admittedly small) work involved in class-side schema changes, I've moved toward avoiding use of class/class-instance variables. I tend to create an application class that is mostly a holder for application data and put a singleton instance in UserGlobals. It is still accessed through class-side methods on the domain classes, but remains intact through class schema changes. James On Mar 10, 2010, at 8:01 PM, Norbert Hartl wrote: > Hi, > > in my newly started project I came to a point where I decided that I don't want to loose data anymore. So I needed to learn something about migration of classes and objects. I'm not really sure if my workflow is a desired one or just awkward. > > I had a class where I accidenitally assigned a class instance var but it should be a class var just. In this classes I have a instance variable instances that holds all instances of this class. Updating the model that changes the vars always led to having all instances lost. So with a few trials I did the following: > > - turned off auto commit and auto migrate > - copied all instances from the class to UserGlobals > - loaded the code with monticello > - copied all instances from UserGlobals to the instance var in the class again > - committed the transaction > - I checked that the old version of the class was position 4 in the class history and the new one 5 > - just did (HRWine classHistory at: 4) migrateInstancesTo: (HRWine classHistory at: 5) > > Is this the way to go or did I miss some things. I read the programmers guide about migration but did not find the exact information how to do this. > > any hints welcomed, > > Norbert > |
On 11.03.2010, at 12:34, James Foster wrote: > Norbert, > > Your approach (described below) is a very good approach. Given that the old class is still available as #4 in the classHistory, you could have avoided the intermediate storage in UserGlobals, but the intermediate step probably simplified things. > Ah, it took me a while to understand what you mean. I just didn't realize all of the implications. To me it appeared that something is being reset while upgrading classes. But in fact it is just that a new class instance is being created. And I'm using a class instance var to keep all instances. And this instance var is still alive just in the older class version. Having auto migrate on renders the situation even more confusing because I have instances already migrated to the new class but being kept in the instance var of the old class. Well, thanks very much for enlighten my path :) > As Dale mentions elsewhere, I am working on a migration strategy, but it assumes that class variables and class instance variables are consistent between versions. If there are to be changes in the class-side schema (as you have done), then some specific handling would be required and something analogous to your approach would have been needed. > I'm fine with that. I think there is barely a chance to make this right under any cirumstances. To me it was the first time approaching class versions and stable upgrades at all. So I was just looking for _a_ work flow that I can use in this situation. > Because of the (admittedly small) work involved in class-side schema changes, I've moved toward avoiding use of class/class-instance variables. I tend to create an application class that is mostly a holder for application data and put a singleton instance in UserGlobals. It is still accessed through class-side methods on the domain classes, but remains intact through class schema changes. > I was thinking about the same. This way it will be much easier to upgrade the domain classes. Another benefit is that this class serves as container for the whole model. Quite useful if you use a tool like Sixx to replicate your model. No need for an extra umbrella. The downside to me is the introduction of yet another platform dependent class in my model. I have hard times to keep up my stuff to work in pharo and in gemstone. And I'm reluctant to make platform dependent versions of my project. Norbert > James > > On Mar 10, 2010, at 8:01 PM, Norbert Hartl wrote: > >> Hi, >> >> in my newly started project I came to a point where I decided that I don't want to loose data anymore. So I needed to learn something about migration of classes and objects. I'm not really sure if my workflow is a desired one or just awkward. >> >> I had a class where I accidenitally assigned a class instance var but it should be a class var just. In this classes I have a instance variable instances that holds all instances of this class. Updating the model that changes the vars always led to having all instances lost. So with a few trials I did the following: >> >> - turned off auto commit and auto migrate >> - copied all instances from the class to UserGlobals >> - loaded the code with monticello >> - copied all instances from UserGlobals to the instance var in the class again >> - committed the transaction >> - I checked that the old version of the class was position 4 in the class history and the new one 5 >> - just did (HRWine classHistory at: 4) migrateInstancesTo: (HRWine classHistory at: 5) >> >> Is this the way to go or did I miss some things. I read the programmers guide about migration but did not find the exact information how to do this. >> >> any hints welcomed, >> >> Norbert >> > |
Hi,
if i right remember, i read about auto 'migration' for class variables. But some test i do, when create a new version of one class, the class variables aren't update to the previous class variables pointer. I wrong? ( I need to update it directly with some command ). Another point: i have my application with some class, each with class variable to manage the relative instances. Now i'm interested to manage some 'enviroment' each separated by other. In Gemstone i remember the namespace support with relative 'Dictionary'. I can manage it in GLASS ? Or i can solve this problematic in another mode ? Thanks for any considerations !!! Dario >> >> Your approach (described below) is a very good approach. Given that the old class is still available as #4 in the classHistory, you could have avoided the intermediate storage in UserGlobals, but the intermediate step probably simplified things. >> > Ah, it took me a while to understand what you mean. I just didn't realize all of the implications. To me it appeared that something is being reset while upgrading classes. But in fact it is just that a new class instance is being created. And I'm using a class instance var to keep all instances. And this instance var is still alive just in the older class version. Having auto migrate on renders the situation even more confusing because I have instances already migrated to the new class but being kept in the instance var of the old class. Well, thanks very much for enlighten my path :) > >> As Dale mentions elsewhere, I am working on a migration strategy, but it assumes that class variables and class instance variables are consistent between versions. If there are to be changes in the class-side schema (as you have done), then some specific handling would be required and something analogous to your approach would have been needed. >> > > I'm fine with that. I think there is barely a chance to make this right under any cirumstances. To me it was the first time approaching class versions and stable upgrades at all. So I was just looking for _a_ work flow that I can use in this situation. > >> Because of the (admittedly small) work involved in class-side schema changes, I've moved toward avoiding use of class/class-instance variables. I tend to create an application class that is mostly a holder for application data and put a singleton instance in UserGlobals. It is still accessed through class-side methods on the domain classes, but remains intact through class schema changes. >> > I was thinking about the same. This way it will be much easier to upgrade the domain classes. Another benefit is that this class serves as container for the whole model. Quite useful if you use a tool like Sixx to replicate your model. No need for an extra umbrella. The downside to me is the introduction of yet another platform dependent class in my model. I have hard times to keep up my stuff to work in pharo and in gemstone. And I'm reluctant to make platform dependent versions of my project. > > Norbert > >> James >> >> On Mar 10, 2010, at 8:01 PM, Norbert Hartl wrote: >> >>> Hi, >>> >>> in my newly started project I came to a point where I decided that I don't want to loose data anymore. So I needed to learn something about migration of classes and objects. I'm not really sure if my workflow is a desired one or just awkward. >>> >>> I had a class where I accidenitally assigned a class instance var but it should be a class var just. In this classes I have a instance variable instances that holds all instances of this class. Updating the model that changes the vars always led to having all instances lost. So with a few trials I did the following: >>> >>> - turned off auto commit and auto migrate >>> - copied all instances from the class to UserGlobals >>> - loaded the code with monticello >>> - copied all instances from UserGlobals to the instance var in the class again >>> - committed the transaction >>> - I checked that the old version of the class was position 4 in the class history and the new one 5 >>> - just did (HRWine classHistory at: 4) migrateInstancesTo: (HRWine classHistory at: 5) >>> >>> Is this the way to go or did I miss some things. I read the programmers guide about migration but did not find the exact information how to do this. >>> >>> any hints welcomed, >>> >>> Norbert >>> >> > |
On 18.03.2010, at 16:58, Dario Trussardi wrote: > Hi, > > if i right remember, i read about auto 'migration' for class variables. > > But some test i do, when create a new version of one class, the class variables aren't update to the previous class variables pointer. > > I wrong? ( I need to update it directly with some command ). Well, I just struggled at this particular point so I might be of help. Maybe you are doing the same mistake I did. If you upgrade a class there is no modification of the class itself. Instead a new class is created and put on top of the classHistory of that particular class. What happens (if you have auto migrate turnde on) is that all instances of the old class are migrated to the new class. I'm not sure if you are talking about class vars or class instance vars. In my case it was class instance vars. Every class has its own instance var so do the versions of a class. If you upgrade than the old class instance still has all the instances while the new one has nothing. If this is the case you can just do (if your instance access method is called #instances): MyClass instances addAll: (MyClass classHistory at: (MyClass classHistory size - 1)) instances I don't know how gemstone works if you really use class vars. But then I would assume that the class var is being migrated. Norbert > > Another point: > > i have my application with some class, each with class variable to manage the relative instances. > > Now i'm interested to manage some 'enviroment' each separated by other. > > In Gemstone i remember the namespace support with relative 'Dictionary'. > > I can manage it in GLASS ? > > Or i can solve this problematic in another mode ? > > Thanks for any considerations !!! > > Dario > > > > >>> >>> Your approach (described below) is a very good approach. Given that the old class is still available as #4 in the classHistory, you could have avoided the intermediate storage in UserGlobals, but the intermediate step probably simplified things. >>> >> Ah, it took me a while to understand what you mean. I just didn't realize all of the implications. To me it appeared that something is being reset while upgrading classes. But in fact it is just that a new class instance is being created. And I'm using a class instance var to keep all instances. And this instance var is still alive just in the older class version. Having auto migrate on renders the situation even more confusing because I have instances already migrated to the new class but being kept in the instance var of the old class. Well, thanks very much for enlighten my path :) >> >>> As Dale mentions elsewhere, I am working on a migration strategy, but it assumes that class variables and class instance variables are consistent between versions. If there are to be changes in the class-side schema (as you have done), then some specific handling would be required and something analogous to your approach would have been needed. >>> >> >> I'm fine with that. I think there is barely a chance to make this right under any cirumstances. To me it was the first time approaching class versions and stable upgrades at all. So I was just looking for _a_ work flow that I can use in this situation. >> >>> Because of the (admittedly small) work involved in class-side schema changes, I've moved toward avoiding use of class/class-instance variables. I tend to create an application class that is mostly a holder for application data and put a singleton instance in UserGlobals. It is still accessed through class-side methods on the domain classes, but remains intact through class schema changes. >>> >> I was thinking about the same. This way it will be much easier to upgrade the domain classes. Another benefit is that this class serves as container for the whole model. Quite useful if you use a tool like Sixx to replicate your model. No need for an extra umbrella. The downside to me is the introduction of yet another platform dependent class in my model. I have hard times to keep up my stuff to work in pharo and in gemstone. And I'm reluctant to make platform dependent versions of my project. >> >> Norbert >> >>> James >>> >>> On Mar 10, 2010, at 8:01 PM, Norbert Hartl wrote: >>> >>>> Hi, >>>> >>>> in my newly started project I came to a point where I decided that I don't want to loose data anymore. So I needed to learn something about migration of classes and objects. I'm not really sure if my workflow is a desired one or just awkward. >>>> >>>> I had a class where I accidenitally assigned a class instance var but it should be a class var just. In this classes I have a instance variable instances that holds all instances of this class. Updating the model that changes the vars always led to having all instances lost. So with a few trials I did the following: >>>> >>>> - turned off auto commit and auto migrate >>>> - copied all instances from the class to UserGlobals >>>> - loaded the code with monticello >>>> - copied all instances from UserGlobals to the instance var in the class again >>>> - committed the transaction >>>> - I checked that the old version of the class was position 4 in the class history and the new one 5 >>>> - just did (HRWine classHistory at: 4) migrateInstancesTo: (HRWine classHistory at: 5) >>>> >>>> Is this the way to go or did I miss some things. I read the programmers guide about migration but did not find the exact information how to do this. >>>> >>>> any hints welcomed, >>>> >>>> Norbert >>>> >>> >> > |
In reply to this post by dario trussardi
On Mar 18, 2010, at 8:58 AM, Dario Trussardi wrote: > Hi, > if i right remember, i read about auto 'migration' for class variables. I don't believe that there is any built-in migration for class variables or class instance variables. > But some test i do, when create a new version of one class, the class variables aren't update to the previous class variables pointer. I wrong? ( I need to update it directly with some command ). I believe that this is the way things work. As mentioned below, I'm working on a migration strategy. Currently, this involves looking at the names in the old class and assigning the values into the new class. For class instances variables, the method Class>>#'atClassInstVar"put:' is useful. For class variables, the method Class>>#' _classVars' gives you direct access to the SymbolDictionary. Once you have that you can add/remove things to make it consistent with the old class. > Another point: > i have my application with some class, each with class variable to manage the relative instances. > Now i'm interested to manage some 'enviroment' each separated by other. > In Gemstone i remember the namespace support with relative 'Dictionary'. > I can manage it in GLASS ? > Or i can solve this problematic in another mode ? As mentioned below, "I tend to create an application class that is mostly a holder for application data and put a singleton instance in UserGlobals." How do you you plan to distinguish your different 'environment' instances? At what point in the application would the environment be selected? Those issues will drive the decision on how to represent it in code. James > Thanks for any considerations !!! > > Dario > > > > >>> >>> Your approach (described below) is a very good approach. Given that the old class is still available as #4 in the classHistory, you could have avoided the intermediate storage in UserGlobals, but the intermediate step probably simplified things. >>> >> Ah, it took me a while to understand what you mean. I just didn't realize all of the implications. To me it appeared that something is being reset while upgrading classes. But in fact it is just that a new class instance is being created. And I'm using a class instance var to keep all instances. And this instance var is still alive just in the older class version. Having auto migrate on renders the situation even more confusing because I have instances already migrated to the new class but being kept in the instance var of the old class. Well, thanks very much for enlighten my path :) >> >>> As Dale mentions elsewhere, I am working on a migration strategy, but it assumes that class variables and class instance variables are consistent between versions. If there are to be changes in the class-side schema (as you have done), then some specific handling would be required and something analogous to your approach would have been needed. >>> >> >> I'm fine with that. I think there is barely a chance to make this right under any cirumstances. To me it was the first time approaching class versions and stable upgrades at all. So I was just looking for _a_ work flow that I can use in this situation. >> >>> Because of the (admittedly small) work involved in class-side schema changes, I've moved toward avoiding use of class/class-instance variables. I tend to create an application class that is mostly a holder for application data and put a singleton instance in UserGlobals. It is still accessed through class-side methods on the domain classes, but remains intact through class schema changes. >>> >> I was thinking about the same. This way it will be much easier to upgrade the domain classes. Another benefit is that this class serves as container for the whole model. Quite useful if you use a tool like Sixx to replicate your model. No need for an extra umbrella. The downside to me is the introduction of yet another platform dependent class in my model. I have hard times to keep up my stuff to work in pharo and in gemstone. And I'm reluctant to make platform dependent versions of my project. >> >> Norbert >> >>> James >>> >>> On Mar 10, 2010, at 8:01 PM, Norbert Hartl wrote: >>> >>>> Hi, >>>> >>>> in my newly started project I came to a point where I decided that I don't want to loose data anymore. So I needed to learn something about migration of classes and objects. I'm not really sure if my workflow is a desired one or just awkward. >>>> >>>> I had a class where I accidenitally assigned a class instance var but it should be a class var just. In this classes I have a instance variable instances that holds all instances of this class. Updating the model that changes the vars always led to having all instances lost. So with a few trials I did the following: >>>> >>>> - turned off auto commit and auto migrate >>>> - copied all instances from the class to UserGlobals >>>> - loaded the code with monticello >>>> - copied all instances from UserGlobals to the instance var in the class again >>>> - committed the transaction >>>> - I checked that the old version of the class was position 4 in the class history and the new one 5 >>>> - just did (HRWine classHistory at: 4) migrateInstancesTo: (HRWine classHistory at: 5) >>>> >>>> Is this the way to go or did I miss some things. I read the programmers guide about migration but did not find the exact information how to do this. >>>> >>>> any hints welcomed, >>>> >>>> Norbert >>>> >>> >> > |
Hi,
i have do some work about this ( for now into pharo image ). 1) when i open a new session i test the path request and i set session instance variable 'applicationSystem' to an relative Smalltalk variable. Example: for path /environment1 i set session instance applicationSystem to Smalltalk at: #'Enviroment1'. for path /environment2 i set session instance applicationSystem to Smalltalk at: #'Environment2'. And all work fine. 2) the Smalltalk #'Environment1' variable manage a dictionary with reference to some collection #Product -> #( p1 p2 p3 ) #Supplier -> # ( s1 s2 s3 ) and go well. Point A ) Now my code define some class class-instance variables but this are in conflict with James write: I've moved toward avoiding use of class/class-instance variables. Any idea to manage this ? Point B ) Another problem is the session reference. In all WA subclass i can reference it with: self session method and access to the relative environment directly. But when for example i'm in classSide method of object subClass ( for example the Product class ) i don't have direct reference to the session environment and i have problem to point at specific data. Anybody have consideration about this specific point or relative to this problematic ? Thanks, Dario
|
On Mar 23, 2010, at 6:26 AM, Dario Trussardi wrote:
Change the class-side methods that return the class (instance) variable to do the global lookup.
|
Hi,
A) OK for the instance of the class i use the Environment reference. This work fine for all classes. But i have class with other class/class-instance variable ( not equal for the classes ). ClassA with: classVariable1 classVariable2. ClassB with: classVariablePippo classVariablePluto. How i can manage it ? I can add to my Environment the: classVariable1-> value1 classVariable2 -> value2 classVariablePippo -> ...valuePippo.. classVariablePluto -> ....valuePluto .. It's a valid solution ?
B) I add, to one my method ( for inspect data ) the : rsl := SessionTemps current. self halt. After when display some data the system erase : Internal Server Error: |
On Mar 23, 2010, at 10:14 AM, Dario Trussardi wrote:
When you execute #'halt' during Seaside execution, you are asking for a copy of the current stack to be saved to the database. By its nature, the SessionTemps intended to be local to the session so the VM prevents you from committing them to the database. Thus, the error. The proper way to use SessionTemps is to put something in and then take it out: SessionTemps current at: #'Environment' put: self rootOfMyApplicationDataBasedOnRequestURL. ... (SessionTemps current at: #'Environment') updateStateBasedOnRecentActivity.
|
Free forum by Nabble | Edit this page |