Corrupt database?

[Jerry Bell]

Hi,

I seem to have some sort of corruption in one of my Magma databases.

I'm running a Seaside application with Magma 0.41gamma1 and  
MagmaSeasideHelper.

I have 2 test images and 2 databases.   Both images can access one of  
the databases with no problems.  Trying to access the other database  
from either image results in a error.   So I assume that there is  
something wrong with the "bad" database and not a problem with my  
images.

The error occurs during initial startup,  beginning with:

^(WAMagmaSoloAuto forApp: 'CCS') rootAt: CCSServerRoot

The error is: STBUser cannot have variable sized instances

Looking through the call stack, things seem to go wrong in  
MaFixedObjectBuffer>>createObjectUsing:.  Here, indexedSize is 2,  
which causes "skeleton" to be "class basicNew: indexedSize"  instead  
of "class basicNew".

The root cause of this appears to be that the MagmaClassIdManager's  
class definitions for the STBUser.  Version numbers are incorrect, or  
out of order in some way.

(results from exploring a MagmaClassIdManager, STBUser classId is 126)

| def |
1 to: 5 do: [:index | def := self definitionForClassId: 126 version:  
index.
			Transcript show: ('Index: ', (index printString),
					' Version: ', (def version printString),
					' ivar count: ', (def namedInstSize printString)); cr ]

Index: 1 Version: 4 ivar count: 5
Index: 2 Version: 5 ivar count: 6
Index: 3 Version: 2 ivar count: 9
Index: 4 Version: 1 ivar count: 10
Index: 5 Version: 3 ivar count: 11

When I look at other class definitions, the index and version numbers  
match.  So something seems wrong.

The instance variable counts look right, but the version numbers  
appear to be wrong.  Also, the inImageSerializer believes that we are  
on version 3:

def := (MaObjectSerializer allInstances first classIdManager  
inImageDefinition: STBUser).
def version -> 3
def namedInstSize -> 11 (which is the correct number)

While in the debugger, I re-ordered the definitions for STBUser by the  
version number and resumed.  This actually resulted in the application  
starting up successfully, and all my data for my newly added users was  
present.

However I'm sure if the in-image definition was thought to be 4 or 5  
then my ivar count would have been off and the STBUsers would have  
failed to load again.

So it appears that there are too many versions in Magmas' class  
definition collection for my class, and those versions are out of order.

Somehow I always manage to make interesting errors!

Also: after re-arranging those class definitions and closing the Magma  
session, closing my image without saving, and restarting the image, my  
application opened with no problems.   So I guess my changes to the  
Magma class definitions were persisted.   However, that does leave me  
with version 4 and 5 definitions; while the in-image version of  
STBUser is 3.   I'm sure I could go in and remove those definitions,  
and close the session and everything will be OK.

So my questions are:

Any idea how this could have possibly happened?

How can I fix it permanently, preferably through a code patch and not  
manual "live" tinkering?  (The bad database I am testing with is a  
copy of a currently deployed system, which is currently working fine  
right now, but I'm sure it will break if I ever close and restart its  
image)

Is there any way to make sure it does not happen again?

Thanks,

Jerry Bell