Migration headache

[Göran Krampe]

Hi!

Chris Muller wrote:
>> 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.

I will take a look at the repo definition, how can I "inspect" the 
object buffers in an easy way? It really would be cool to have some kind 
of low level explorer that does NOT deserialize/serialize these guys.

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

Right.

>  The best way is to update your references to Q2User to new instances
> of Q2PersonalUser, but I understand this may not be practical.

Right. :)

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

Yes, but... let's say I have tons of objects in the db with this 
superfluous ivar in them. Every time I pull one of those guys into the 
image and changes it and commits it back - it will warn me. Fine. But 
how do I fix it "bulk wise"? I could iterate over them, but how do I 
tell Magma that:

"Yes, consider it modified, although it is not, but I want to commit and 
truncate all these guys now in order to not get warnings for the rest of 
my life..." :)

regards, Göran