Corrupt database? (FIX)

Jerry Bell jdbell at oxfordmetamedia.com
Tue May 12 19:47:31 UTC 2009


Hi all,

Let me preface this by saying that the problems I've been seeing are  
almost certainly due to something I've done horribly wrong, and it's  
likely that these changes won't be useful for anyone else.  If they  
are useful to someone, they will require some tweaking for your  
specific problem.

Regardless, here is a fix that seems to work for me.

Attached are 2 changesets - DBHackFix and NoOverwriteVersion.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: NoOverwriteVersion.4.cs
Type: application/octet-stream
Size: 1651 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/magma/attachments/20090512/b9dede97/NoOverwriteVersion.4.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DBHackFix.2.cs
Type: application/octet-stream
Size: 1280 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/magma/attachments/20090512/b9dede97/DBHackFix.2.obj
-------------- next part --------------


Here's how I fixed my database:

1) Started an image and loaded DBHackFix - this let me open my  
database successfully.
2) Ran the following code, which fixes my instances on disk.

session := MagmaSession openLocal: 'magma'.
session connectAs: 'test'.

root := session root.

session begin.
serializer := session serializer.
classIdManager := serializer classIdManager.
defs := classIdManager classDefinitionsById at: 126.
defs doWithIndex: [:each :index | each version: index].
session commit.
session disconnectAndClose.

3) Closed the image without saving

At this point, the database is consistent and everything works fine,  
until I start up my application and try to add a new instance of  
STBUser and restart the image.  Then everything breaks again.    It  
seemed as if the class definition versions for STBUser were being set  
wrong.   (All other classes in the database seem to be fine).

So, I tried to track down what was happening by changing  
MaClassDefinition>>version to this:

version: anInteger

	(id = 126)
		ifTrue:[self halt].
	version _ anInteger

I'm not sure exactly what is happening or why, but it seems as if the  
first class definition of STBUser encountered in my database is  
version 4, which is the latest in the image.  However in  
MaClassIdManager>>addClassDefinition: the version is then set to the  
current number of known STBUser class definitions, which is 1.   So, I  
changed the version: method in MaClassDefinition to ignore the new  
version, unless the current version is nil or zero, which are needed  
when a new class definition is created.   I also changed  
MaClassIdManager>>ensureClassDefinitionsFor: so that a  
SortedCollection sorted by version number is used for the class defs,  
instead of an OrderedCollection (as suggested by Chris).   These  
changes are in the NoOverwriteVersion changeset.

As I said, I'm still not sure of what the root cause of the problem  
is.   I don't think there are other instances of STBUser in my  
database with other class def version numbers, if there were I would  
have expected the MagamFileTraverser code would have seen them.    
Perhaps all class definitions are stored somewhere in the database,  
and somehow the definitions for my STBUser ended up out of order?

Regardless, next step is:

4) Load NoOverwriteVersion changeset into the image, and save the image.
5) Start the image again.  Start application as normal.  Everything  
should work OK from here on.

Surprisingly enough this seems to work fine, I've been able to add new  
STBUser instances as well as other objects, and I've been able to add  
two instance variables to STBUser along with new instances after each  
instance variable is added.

============

I'd like to thank Chris for his help and of course all of his work on  
Magma.  It's a great system and it was nice to be able to use the  
usual Smalltalk tools to track down and fix my problem, even though it  
was  a pretty low level issue and was a little strange.  These sorts  
of experiences only increase my confidence in Magma.

Thanks,

Jerry









More information about the Magma mailing list