It turned out primitiveChangeClassTo: worked fine! I will blog about the details. It would also be nice to have more info on available hooks for doing migration, or add such hooks. :)
Hmmm.. I'm not sure how Magma will respond to that. It *seems* like it should be fine because it should pick up the new classId and commit. But please do proceed with caution going forward and make sure all is well before deploying this model! I'm not sure I have enough information give exact advice but here is how Magma works so you may be able to determine the proper course.
- As part of the repository Definition, there is a Dictionary of "classDefinitionsById", keyed by the classId, valued by an OrderedCollection of MaClassDefinitions. - Each MaClassDefinition is for a particular shape of that class name, shape defined by its "allInstVarNames". When some session commits an instance of that class with different set of instVarNames, an additional MaClassDefinition is added to the OrderedCollection at that classId. - Every object buffer knows its #classId and #classVersion, identifying the exact shape of the object.
What you want to do is change each Q2User object-buffer to point to the proper version (probably 1) of the new classId for Q2PersonalUser. The best way is to update your references to Q2User to new instances of Q2PersonalUser, but I understand this may not be practical.
And oh, I get this truncation warning
- I understand it, but how do I make them disappear? Or in other words - how
do I get Magma to grok the new class shape? :)
The truncation warning occurs when the buffer for an object downloaded into an image from the server (i.e., via a proxy-mat read request) has instVars names that are not present for that class in that image. IOW, the *buffer* has a link to an object that the client image has no slot for. This means a reduced MaClassDefinition for that "shape" of object will also be created if not already present if change to that object is committed. Once the object is committed, the ObjectBuffer will refer to the new classVersion and the conditions that generate the warning will no longer be present the next time.
Magma handles class-shape changes and renames "out of the box" but more complex migrations such as hierarchy refactorings must be addressed on a case-by-case basis, like what you have here.
- Chris
On Tue, Mar 3, 2009 at 3:38 PM, Göran Krampe goran@krampe.se wrote:
Hi!
Chris Muller wrote:
Hi Göran, I recommend using the latest r42 alpha code as you have.
Good! :)
I'm not sure what happened with the SortedCollections, but I'm glad you got it fixed.
Yeah, got past that.
Unfortunately, Magma does NOT support become through the session, because that would require knowing all references to an object in the huge repository. But yes, the MagmaFileTraverser could be useful for performing such a migration..
It turned out primitiveChangeClassTo: worked fine! I will blog about the details. It would also be nice to have more info on available hooks for doing migration, or add such hooks. :) And oh, I get this truncation warning
- I understand it, but how do I make them disappear? Or in other words - how
do I get Magma to grok the new class shape? :)
regards, Göran
Magma mailing list Magma@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/magma