Dealing with a Magma index that's out of step

[Nick Brown]

On Tue, Nov 13, 2012, at 04:07 PM, Chris Muller wrote:
> Hi Nick,
> 
> > 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.)
> 
> Hm, this should never happen.  Magma writes to the DB atomically,
> including index updates.  Strange.
> 
> > 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.)
> 
> Yes, that appears to be true.  See
> MagmaCollectionManager>>#processRemovesIn: for the method that
> actually does this.  I wonder if temporarily removing the "didRemove"
> guard would have worked for you?  Hm, I'm actually wondering whether
> that guard is really necessary..
> 
> > 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.
> 
> Just a note:  Objects can be added multiple times to a
> MagmaCollection, so if it was in there more than once it would be
> indexed more than once too.  Doesn't sound like that was the case this
> time but, just fyi.
> 
> > 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?
> 
> You could do a #removeIndexNamed: followed by #addIndex: to force a
> full rebuild.
> 
>  - Chris

Thanks Chris. 

For some reason I had it in my head that indexes only captured
collection contents added *after* the creation of the index, but I'm
glad to see I'm totally wrong about that. 

If this problem should ever happen again, hopefully I'll be able to do a
bit more of a postmortem on it. In the meantime I'll add a method to my
application to recreate the indexes, per your suggestion.

Cheers,
Nick