Migration headache

[Chris Muller]

> 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 at 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 at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/magma
>