Re: NON-mysterious EOF problem
Re: NON-mysterious EOF problem
- Subject: Re: NON-mysterious EOF problem
- From: Chuck Hill <email@hidden>
- Date: Mon, 26 Jan 2004 19:42:56 -0800
The only luck I've had with these is using forgetObject() on them. And, I
think, nulling the reference. You could try doing this in an
EODatabaseContext delegate:
public boolean databaseContextFailedToFetchObject(EODatabaseContext context,
Object object,
EOGlobalID globalID) {
EOEditingContext ec = ((EOEnterpriseObject) object).editingContext();
ec.forgetObject(object);
return true;
}
I don't know what the side effects of this might be, or what returning true
might to do to hose EOF. If you have time to test this out I'd love to
hear about the results. :-)
Now as to what I actually do... I've had a lot of trouble recently with
delete rules. In 5.1.3, if a delete rule resulting in a fault firing that
had to be resolved by a trip to the database, then the EC internal state
got hosed. Badly. Inserts became updates, deletes became updates, general
weirdness ensued. Much gnashing of teeth and complaints about random error
messages and threats of gnashing of developers. I'm 95% certain that this
is still the case in 5.2.2. I still see the same symptoms, but I've not
done a full reproduction case yet. So many bugs, so little time...
Anyway, back to our story. One of the things I ended up writing was a class
to follow the delete rules and ensure that all the faults had been fired
before calling saveChanges. You could do the same thing and before firing a
fault, check if it was a dummy fault eo. If so, null the reference and
forget the dummy fault eo instead of firing it. Wrapped up in an EC
subclass so that it steps in automatically as needed and it is not so bad.
Chuck
At 06:06 PM 26/01/2004 -0600, Jonathan Rochkind wrote:
>Okay, I have an EOF problem that I actually understand! Hooray! But
>I'm not sure the right way to solve it.
>
>Imagine a many-to-many relationship. It's not flattened, it's
>exposed. Let's call it Person, Unit, and the 'join' entity
>PersonUnitJoin. All the delete rules are set appropriately.
>
>Now let's imagine a PersonUnitJoin object/row exists, which has a
>foriegn unitID key, theoretically pointing to a Unit, except----that
>Unit doesn't exist. It's bad data, it's a foreign key that does not
>actually exist. Of course this is bad, and we strive to avoid bad
>data as much as possible, but sometimes for mysterious reasons we
>can't figure out it's there anyway, and we want our code to tolerate
>it as much as possible.
>
>So, now we're deleting the Person. One of that person's
>PersonUnitJoin's is one of these bad data, with an invalid unitID.
>When EOF does the propagateDeleteWithEditingContext and follows all
>the join rules---when it gets to this bad PersonUnitJoin and triggers
>it's fault to Unit, you wind up with one fo those weird
>'ghost'/'missing' EOs, which has all of it's values set to null.
>When the propagate delete code tries to operate on this weird ghost
>Unit---you wind up with an exception.
>
>What can I do to properly and succesfully delete all this stuff,
>including the 'bad data' PersonUnitJoin, despite the fact of the bad
>data. Sorry, maybe I didn't explain this very well, but hopefully
>the EOF experienced understand what I'm talking about.
>
>I can think of several possible solutions, but most of them seem to
>lead to more likely problems. I'm wondering if anyone has any advice.
>
>The actual stack trace that occurs in such a situation is pasted
>below. (CLACustomRecord is my own custom subclass that some of my EOs
>have, it extends EOGenericRecord, and it doesn't do anything unusual
>in propagateDelete, I don't think).
>
>
>EOCustomObject.java 987 excludeObjectFromPropertyWithKey
>Mail.java 169 removeFromPersonMailRecords
>Method.java NA invoke
>NSSelector.java 120 _safeInvokeMethod
>EOCustomObject.java 1011 removeObjectFromPropertyWithKey
>EOClassDescription.java 478 propagateDeleteForObject
>EOCustomObject.java 688 propagateDeleteWithEditingContext
>CLACustomRecord.java 246 propagateDeleteWithEditingContext
>EOClassDescription.java 523 propagateDeleteForObject
>EOCustomObject.java 688 propagateDeleteWithEditingContext
>CLACustomRecord.java 246 propagateDeleteWithEditingContext
>Person.java 1018 propagateDeleteWithEditingContext
>EOEditingContext.java 2137 propagateDeletesUsingTable
>EOEditingContext.java 2099 _processDeletedObjects
>EOEditingContext.java 1653 _processRecentChanges
>EOEditingContext.java 3159 _prepareForPushChanges
>EOEditingContext.java 3115 saveChanges
>_______________________________________________
>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.
>
--
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.