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