Hi Mike,
Thanks for responding.
directly above that, it calls:
final NSArray deletedObjectsToFlushInParent = ERXEOControlUtilities.localInstancesOfObjects(parentEC, ec.deletedObjects());
... anyone know if there is there anything weird about performing this operation in editingContextWillSaveChangeson a pending delete from a child to a parent? Mark -- you might checkout the Wonder source and comment that block of code just to try. I don't think it will have any affect, but who knows.
I have the source, but wasn't quite sure about all the ins and outs of getting it to compile. What I did do was create a class that inherited from ERXEnterpriseObject.Observer, and then registered my class as the listener instead without calling any of super's implementations (thus avoiding that block of code). I still got the same results, though.
Also, if you don't have this in a nested EC, and just delete them directly, does it still fail? (not that this will solve your problem, but it might narrow down possible failure points)
I was thinking the same thing early in the process, so I tried using EOUtilities.localInstanceOfObject to bring the EOs into the nested EC and then delete them there, but got the same problem.
Do you ever invalidate EO's? I notice in some source you posted before that you have a refresh() method that invalidates the EO. Does this only get called during handling an EOGeneralAdaptorException, or possibly somewhere else also? Calling invalidate deletes snapshots and can /potentially/ cause a problem like what you're seeing.
The only place in my code anywhere that I call invalidateObjectsWithGlobalIDs is in that refresh method that gets called only when there is an EOGeneralAdaptorException. I've verified that this code is not getting called anywhere leading up to or during the problematic code execution.
Oh, and how exactly are you creating your two editing contexts? Can you post that code just for completeness?