27 Apr
2011
27 Apr
'11
7:45 a.m.
Thanks for tip regarding sixx. Anyway, what bothers me is embeded inst var
of PRLink that existed in both 1.1 and 1.2. But 1.2 expects it to be true or
false, while my 1.1 PRLinks have arrays in them that contain some data. Now
I could overwrite those arrays with true or false, but what about
information that those arrays contained should I store it somewhere else?
So the question is more what was meaning of embeded inst var before, what is
now and how should they be logically migrated?
Thanks,
Davorin Rusevljan
On Apr 26, 2011 10:54 PM, "Lukas Renggli" <renggli(a)gmail.com> wrote:
Do you have some advice what to do with embeded inst
vars of PRLink(s),
1.2
expects them to be ...
You have to figure out
how to move the contents into the right
variables using #instVarAt: and #instVarAt:put:. However, in your case
it is probably easier if you use SIXX -- or try to adapt the
import/export code to use SmartRefStream -- that both can handle
instance variable changes. Then you only need to fix the "new"
variables.
Lukas
--
Lukas Renggli
www.lukas-renggli.ch
_______________________________________________
Magritte, Pier a...
27 Apr
27 Apr
8 a.m.
New subject: More Import woves
To find out about the instance variables you have to compare the code,
i don't remember these changes of the top of my head.
There is something else you might to try: There should be a class
PRMigrations (or similar, I don't have an image to verify) with a
bunch of class side methods that I used to bring the objects along
from the first version of Pier to today. Run #initialize after import
to give it a try. Not sure it handels well a non-incremental change
like in your case, but it is relatively safe to run as it does all
kind of verifications to validate and fix the model.
Lukas
On Wednesday, 27 April 2011, Davorin Rusevljan
<davorin.rusevljan(a)gmail.com> wrote:
Thanks for tip regarding sixx. Anyway, what bothers me
is embeded inst var of PRLink that existed in both 1.1 and 1.2. But 1.2 expects it to be
true or false, while my 1.1 PRLinks have arrays in them that contain some data. Now I
could overwrite those arrays with true or false, but what about information that those
arrays contained should I store it somewhere else?
So the question is more what was meaning of embeded inst var before, what is now and how
should they be logically migrated?
Thanks,
Davorin Rusevljan
On Apr 26, 2011 10:54 PM, "Lukas Renggli" <renggli(a)gmail.com> wrote:
--
Lukas Renggli
www.lukas-renggli.ch
Do you have some advice what to do with embeded
inst vars of PRLink(s), 1.2
expects them to be ...You have to figure out how to move the contents into the right
variables using #instVarAt: and #instVarAt:put:. However, in your case
it is probably easier if you use SIXX -- or try to adapt the
import/export code to use SmartRefStream -- that both can handle
instance variable changes. Then you only need to fix the "new"
variables.
Lukas
--
Lukas Renggli
www.lukas-renggli.ch
_______________________________________________
Magritte, Pier a...
9:03 a.m.
New subject: More Import woves
On Wed, Apr 27, 2011 at 8:00 AM, Lukas Renggli <renggli(a)gmail.com> wrote:
To find out about the instance variables you have to
compare the code,
i don't remember these changes of the top of my head.
There is something else you might to try: There should be a class
PRMigrations (or similar, I don't have an image to verify) with a
bunch of class side methods that I used to bring the objects along
from the first version of Pier to today. Run #initialize after import
to give it a try. Not sure it handels well a non-incremental change
like in your case, but it is relatively safe to run as it does all
kind of verifications to validate and fix the model.
Thanks, I will give it a whirl.
Davorin Rusevljan
11:08 p.m.
New subject: More Import woves
There is
something else you might to try: There should be a class
PRMigrations (or similar, I don't have an image to verify) with a
bunch of class side methods that I used to bring the objects along
from the first version of Pier to today. Run #initialize after import
to give it a try. Not sure it handels well a non-incremental change
like in your case, but it is relatively safe to run as it does all
kind of verifications to validate and fix the model.
Thanks, I will give it a whirl.
Davorin Rusevljan
28 Apr
28 Apr
5:26 p.m.
New subject: More Import woves
Now Lukas,
please bear with me.
I have fetched the 1.1 image that is running my blog to my local
machine for inspection, and as you have suggested the origin of
problems is that the layout of instance variables has changed from 1.1
to 1.2 and deserialization stuffs data into wrong slots, for instance
old PRLink had instance variables:
'reference' 'embedded' 'parameters'
While the new one has:
'reference' 'owner' 'embedded' 'parameters'
which results in parameters getting stuffed into embedded inst var, so
embedded after import suddenly has all those arrays in them instead of
nice booleans the code expects.
Now I have run a snippet of code to list all subclasses of PRObject in
old and new image along with inst vars they have, and the diffed that.
Result is 9 classes that have changed layout. I suspect some of them
can not appear in serialized data, but I guess you will know better.
Anyway for those 9 classes I would kindly ask you to give me a hint
how to correctly migrate them, i.e. what to stuff into empty slots. So
here goes the list (class, then old layout then new):
----------
PRAddCommand
#('name' 'type' 'link')
#('name' 'type' 'link' 'title')
----------
PRCommand
#('timestamp' 'context' 'answer' 'checked')
#('timestamp' 'context' 'checked' 'successAnswer'
'cancelAnswer' 'answer')
----------
PRComponent
#('componentClass' 'settings')
#('componentClass' 'settings' 'link')
----------
PRGoogleGadget
#('url' 'xml' 'settings' 'description')
#('url' 'xml' 'translations' 'settings'
'description')
----------
PRInternalLink
#('owner' 'target' 'anchor')
#('target' 'anchor')
----------
PRLink
#('reference' 'embedded' 'parameters')
#('reference' 'owner' 'embedded' 'parameters')
----------
PULogin
#('ancestor' 'username' 'password' 'user')
#('username' 'password' 'user')
----------
PUMember
#('name')
#('name' 'comment')
----------
PUUser
#('password' 'groups' 'superuser')
#('password' 'token' 'groups' 'superuser'
'firstName' 'lastName' 'email')
Thanks!
Davorin Rusevljan
http://www.cloud208.com/
6:41 p.m.
New subject: More Import woves
Now I have run a snippet of code to list all
subclasses of PRObject in
old and new image along with inst vars they have, and the diffed that.
Result is 9 classes that have changed layout. I suspect some of them
can not appear in serialized data, but I guess you will know better.
Subclasses of PRCommand should not be part of the serialized data.
Anyway for those 9 classes I would kindly ask you to
give me a hint
how to correctly migrate them, i.e. what to stuff into empty slots. So
here goes the list (class, then old layout then new):
You just have to make sure that a value in inst-var 'x' ends up in
inst-var 'x'. And that new variables are initialized with 'nil'.
"PRMigration initialize" fixes the rest.
Lukas
--
Lukas Renggli
www.lukas-renggli.ch
29 Apr
29 Apr
12:30 a.m.
New subject: More Import woves
On Thu, Apr 28, 2011 at 6:41 PM, Lukas Renggli <renggli(a)gmail.com> wrote:
You just have to make sure that a value in inst-var
'x' ends up in
inst-var 'x'. And that new variables are initialized with 'nil'.
"PRMigration initialize" fixes the rest.
Ok, there were still things to fix by hand after the PRMigration
initialize, but I think I have managed to import kernel in the end.
Although something along the way started html escaping parts of the
html in my heading, but I guess I will look into that next day.
Many thanks!
Davorin Rusevljan
http://www.cloud208.com/
5049
days inactive
5050
days old
6 comments
2 participants
participants (2)
-
Davorin Rusevljan -
Lukas Renggli