Hi Hilaire,
When populating a MagmaCollection I got error with index, because I used the wrong selector for the index.
Can you provide a lot more detail? What was the index type and what did you discover you did wrong? What error was reported and then how did you fix it? I ask because the next sentence implies this is what led to the problem..
Also, this is a development database right? You are writing new code with new indexes and accidently used the wrong selector. Anytime you are doing exploratory, volatile stuff like this, you definitely want to have a safe backup of your database if the data is important. Just like a Smalltalk image model can get goofed up, the db model CAN get goofed up during development.
But file corruption should NEVER happen, so that's why I'm very curious about the details of what led up to this problem. If there is a way for the files to be corrupted, even through misuse, I want to be sure to prevent that.
I fix that, then I start to get "class definition unknow" error message,
99% of the time, the root cause of this error is your client has extended the protocol beyond what the server expects. By looking in the right place in the debugger it will show which class belongs to the new id that the server could not interpret. First, look at what id it says is not found in the server's debugger, then explore your client MagmaSession which sent the request:
aMagmaSession -> link -> serializer -> classIdManager -> classesById
One possibility is you creaed a new index-type that was not present on the server, therefore not part of the servers protocol, so it couldn't materialize it..
then my whole data is unaccessible (lost),
I'll bet it's not lost. You can probably recover it using Magma's tools, but you will need to get familiar with them..
then from the server I stop and restrat (even restarting Squeak), and now each time I start the Magma server I got the two following messages (capture here).
This error is signaled when Magma is unable to materialize the repository's class definitions because of ANY Error. If you look at the method #materializeClassDefinitions, it will have captured the high-level exception Error. Can you please inspect the :err variable and see what error it encountered?
I am sure I do a lot of mistake when using Magma, but now I start to get anxious with it.
Well, thankfully the Magma file format relatively simple and extremely well-documented (thanks to Brent and his team). All of its "records" are encapsulated by first-class objects so you can easily "browse" or interrogate (via script) the contents of the database and see where some record has "bad data" and then fix it.
Contrast this with something like ImageSegments. Heaven forbid some sort of corruption in an ImageSegment which utilizes low-level bytes without first-class representations of its parts and, to my knowledge, is not well documented..
Magma does does have *some* checks because I knew people would be "rough" with it, but there are obviously some places that still need better checks (like letting the client extend the protocol). You have been very helpful in reporting these issues and finding some bugs (and the DNU in your screen shot is another bug you've found, I'll fix that).
If you must recover this file, check out pages 1-4 of the file-format documentation
http://wiki.squeak.org/squeak/uploads/2665/magma_file_format.pdf
and then e-mail me and I will help you.
Regards, Chris