RE: EOObjectNotAvailableException
RE: EOObjectNotAvailableException
- Subject: RE: EOObjectNotAvailableException
- From: "Watkins, Garry" <email@hidden>
- Date: Thu, 27 Jul 2006 13:26:41 -0400
- Thread-topic: EOObjectNotAvailableException
Ken, thanks for understanding my pain. I am in the situation that you
described. However, I think that I may have found a delegate entry
point to trap the fault.
If I use the databaseContextShouldFetchObjectFault, I am hoping that I
can get enough information from the fault to determine if it is one of
my optional relationships, and put a marker on the ThreadLocal. Then
when the databaseContextFailedToFetchObject method is invoked, I can
check for the marker, and supress the exception.
Just thought that I would run this by the list to see if there are any
flaws in my idea. I am getting ready to run a simple test on it now.
Thanks
Garry
-----Original Message-----
From: Ken Anderson [mailto:email@hidden]
Sent: Thursday, July 27, 2006 10:10 AM
To: Anjo Krank
Cc: Watkins, Garry; email@hidden
Subject: Re: EOObjectNotAvailableException
Anjo,
Unfortunately, that's not always possible. On my last big project, EOF
came long after the database schema was defined and in-use. It's not
uncommon for there to be a primary row, with multiple optional rows, all
with the same primary key. This was considered normal and acceptable
before unique integer primary keys were being used. So, to paraphrase,
I understand Garry's pain :)
Ken
On Jul 27, 2006, at 1:11 AM, Anjo Krank wrote:
>
> Am 25.07.2006 um 17:20 schrieb Watkins, Garry:
>
>> Really not the answer that I wanted. Personally, I think that it is
>> a bug in EO, if the relationship is defined as NOT mandatory, and it
>> encounters a EOObjectNotAvailableException it should return null.
>> However, I want to continue to use EOGenericRecords since it is
>> mainly a reporting type application. Does anyone know where the
>> Fault is triggered inside the EO stack so that I might be able to
>> trap the operation with AspectJ? This would also require that I have
>> the EORelationship that triggered the fault.
>
> If you have a key that points into nirvana, your data is broken and
> should be fixed. EOF certainly should *not* return null in this case.
>
> You could probably write an accessor to your relationship and trap the
> exception there or get the committed snapshot in the EODBC or EODB and
> patch it to be null. But the easiest route is to fix your data.
>
> Cheers, Anjo
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
> 40anderhome.com
>
> This email sent to email@hidden
Confidential & Privileged
Unless otherwise indicated or obvious from its nature, the information contained in this communication is attorney-client privileged and confidential information/work product. This communication is intended for the use of the individual or entity named above. If the reader of this communication is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error or are not sure whether it is privileged, please immediately notify us by return e-mail and destroy any copies--electronic, paper or otherwise--which you may have of this communication.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden