Corrupt database?

[Jerry Bell]

No, STBUser is a subclass of STBModel which is a subclass of Object.

Thanks,

Jerry

On May 7, 2009, at 12:50 PM, Chris Muller wrote:

> Is STBUser a kind of Set?
>
> On Thu, May 7, 2009 at 12:32 PM, Jerry Bell <jdbell at oxfordmetamedia.com 
> > wrote:
>> 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
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Magma mailing list
>> Magma at lists.squeakfoundation.org
>> http://lists.squeakfoundation.org/mailman/listinfo/magma
>>