Dealing with a Magma index that's out of step

[Nick Brown]

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