Re: weird EOF exception in propagateDeleteWithEditingContext
Re: weird EOF exception in propagateDeleteWithEditingContext
- Subject: Re: weird EOF exception in propagateDeleteWithEditingContext
- From: Chuck Hill <email@hidden>
- Date: Thu, 28 Aug 2003 11:01:06 -0700
At 12:49 PM 28/08/2003 -0500, Jonathan Rochkind wrote:
>Okay, interesting possiblities, thanks. It's not clear to me how to detect
>them, let alone how to _solve_ them, but it gives me some starting points.
>I'll try to put some code in to detect those conditions, around the points
>I'm getting the mysterious exceptions.
>
These methods are mutually exclusive.
/**
* Delegate on EODatabaseContext that gets called when a to-one fault cannot
* find its corresponding data in the database. The object is a cleared
fault.
* An exception is thrown to bring attention to this problem.
*/
public boolean databaseContextFailedToFetchObject(EODatabaseContext context,
Object object,
EOGlobalID globalID) {
EOEditingContext ec = ((EOEnterpriseObject) object).editingContext();
// We need to refault the object before raising, otherwise, if the caller
// traps the exception, it will be a successful lookup the next time a
fault
// with the same global id fires. NOTE: refaulting in a
sharedEditingContext
// is illegal, so we specifically check for that special case.
if (! (ec instanceof EOSharedEditingContext)) {
context.refaultObject((EOEnterpriseObject) object, globalID, ec);
}
String failureMessage = "Failed to fetch " + object.getClass() +
" with globalID " + globalID;
RuntimeException integrityException = new
RuntimeException(failureMessage);
// When thrown during one of the R-R loop phases (or due to Key-Value
// coding?), the integrityException gets swallowed. This seems to happen
// often. To accomodate this, the exception should be written to an error
// log that is checked so that it is not lost.
NSLog.err.appendln(failureMessage);
throw integrityException;
}
/**
* EOF resolves faults for objects that don't exist in the database to a
dummy
* object with empty attributes. This method detects whether the parameter
* is such a dummy object.
*/
public static boolean isDummyFaultEO(EOEnterpriseObject anObject) {
boolean isDummyFaultEO = false;
// This method will fail if the object is still a fault. We fire the
fault
// so that the correct result is returned.
if (anObject.isFault()) {
anObject.willRead();
}
EOEditingContext ec = anObject.editingContext();
EOGlobalID globalID = ec.globalIDForObject(anObject);
// NB: objects with temporary globalIDs legitimately have no DB
snapshots,
// since these are by definition not yet saved to the database.
if (globalID != null && ! globalID.isTemporary()) {
// Find the EODatabaseContext instance associated with anObject, or
// null if no databaseContext association can be found.
EOObjectStoreCoordinator rootStore =
(EOObjectStoreCoordinator)ec.rootObjectStore();
EODatabaseContext dbContext =
(EODatabaseContext)rootStore.objectStoreForObject(anObject);
isDummyFaultEO = (dbContext.snapshotForGlobalID(globalID) == null);
}
return isDummyFaultEO;
}
>Both seem plausible to me. In particular, I know that I'm getting _other_
>exceptions related to 'wrong EC', in parts of my code that no matter how
>long and deep I look at them, I can't figure out ANY WAY that an EO of the
>wrong EC could be involved.
>
Use eoGenerator to change the methods to log out crossed ec errors. e.g.
public void addToEmployees(Employee newPerson) {
if (editingContext() != newPerson.editingContext()) {
NSLog.out.appendln(new RuntimeException("Crossed EC Backtrace");
}
etc.
}
>Yet I have an exception of the form that's
>usually only thrown when you get a wrong EC. [It would help if an exception
>that actually said 'Cross-EC relationship' were thrown, instead of the
>mysterious other exceptions. When I switched from using nested to using
>peer ECs, the type of exception thrown for a cross-EC relationship changed
>entirely, confusing me at first. ]
>
>The first one seems actually the best guess for how you'd get a null for a
>relationship. I know those dummy EOs do have null, instead of empty arrays,
>for relationship. Hmm, I wonder how the hell I deal with that. Especially
>if it's another instance entirely doing the deleting, at just the wrong
>time. I suppose I can try to reproduce that manually, to see if it results
>in the error in question. But I would still have no idea how to solve
>it! I guess it's an EOF bug. But one that Apple is going to have trouble
>fixing too, I bet.
>
Yeah, I think it will get pretty nasty.
Chuck
>--Jonathan
>
>At 10:30 AM 8/28/2003 -0700, Chuck Hill wrote:
>>A couple of possibilities come to mind:
>>
>>1. The employee is actually a "dummy fault eo" due to some referential
>>integrity problem. This might happen if it has been deleted in another
>>instance after the relating object has been fetched into the one producing
>>the error. I *think* that is possible. And very nasty to deal with.
>>
>>2. One of the related objects is in a different EC. I'd consider this less
>>likely, but I don't know how removeObjectFromBothSidesOfRelationshipWithKey
>>(ever wanted an e-mail client with code completion?) is implement or,
>>indeed, if propagateDeleteForEditingContext() uses that. It might do
>>somethink like destinationObjectForSourceGlobalIDAndRelationship() (yeah, I
>>just made that up) which fails when it can not find the object in the EC.
>>
>>
>>
>> >Note
>> >that I still have the old 5.0-generated code for removeFromRelationship,
>> >which is why the stack trace points me to a null pointer exception that I
>> >know is from deptJoinObjects() returning null.
>> >
>>That sounds more like a dummy fault object, no?
>>
>>
>>
>>Chuck
>>
>>
>>--
>>
>>Chuck Hill email@hidden
>>Global Village Consulting Inc. http://www.global-village.net
>
>
--
Chuck Hill email@hidden
Global Village Consulting Inc. http://www.global-village.net
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.