Hi Chris and all,
I have Magma in a small Seaside application, used internally at my workplace. It's running on Pharo 1.3 using the 1.3 patch and load script from the Squeak wiki.
Primarily we keep domain objects inside a MagmaCollection, with various indexes, and occasionally a commit will cause an indexed value to change, and of course we use #noteOldKeysFor: to ensure the indexes get updated when this happens.
A couple of days ago we had an incident where a runaway process on a server cause it to become largely unresponsive. This server also holds the Magma repository. It appears that as a result of Magma operating through this incident, a commit on a domain object succeeded, but the index update failed, so the index continued to reflect the old state of the object. (I can't prove this is the cause, but it seems to me likely.)
Hitting Google for advice on fixing the Magma index, I found a thread on this list [1] where the given solution to this sort of index problem is to remove and re-add the object to the collection. However, when I remove the object from the collection, it doesn't get removed from the index (presumably because the index entry removal depends upon the state of the object being correspondent, which of course in this case, it isn't.)
On re-adding the object to the collection, it gets indexed with its correct state, but this is in *addition* to the old index entry. So that didn't fix my problem.
I did subsequently fix it by reverting the state of the domain object to match the index, then progressing the object forward through its normal process, successfully updating the index as it went.
So, the questions are: 1 - Is there another way of fixing the problem, that I missed? 2 - Ought there to be clearly defined interfaces for forcing in & out particular index entries, or forcing entire index rebuilds?
Thanks, Nick
[1] http://thread.gmane.org/gmane.comp.lang.smalltalk.squeak.magma/914/focus=914