Re: non-existent target of existing key in relationship
Re: non-existent target of existing key in relationship
- Subject: Re: non-existent target of existing key in relationship
- From: Ray Kiddy <email@hidden>
- Date: Fri, 14 Jan 2011 14:39:43 -0800
On Jan 14, 2011, at 10:50 AM, Chuck Hill wrote:
>
> On Jan 14, 2011, at 9:14 AM, Ray Kiddy wrote:
>
>>
>> I cannot decide if this is something that EOF should or could deal with. On the one hand, it is clearly not correct. But it is clear what is happening, so EOF could just do the thing that makes it work. I have tables that look like this:
>>
>> table 1 for eo1:
>>
>> pk name
>> ---- --------
>> 1 thingA
>> 2 thingB
>> 3 thingC
>>
>> table 2 for eo2:
>>
>> pk fkey name
>> ---- ------ --------
>> 1 1 other01
>> 2 2 other02
>> 3 2 other03
>> 4 3 other04
>> 5 4 other05
>>
>> As you might guess there is a relationship eo1<-->>eo2.
>>
>> I am importing this data from an external source. There is obviously intended to be a "thingD" with a pk of 4. It might be an error that it does not yet exist. But, even if it is an error, it may or may not be fixed. This could be something I just have to deal with.
>>
>> Right now, one gets an exception, something like "no eo1 object found for pk 4".
>>
>> Would there be a sensible way for EOF to allow one to model this? Perhaps a "provisionally required" to-one join from eo2 to eo1? I am not sure. Or, I could just stomp on the bad fkey value on import. But EOF is smart, yes? It could do something smart. Any thoughts?
>
> It can do three things that I can think of:
> 1. Throw an exception as the object store is inconsistent, this is what Wonder does
> 2. Silently discard the relationship. That seems undesirable to me. Ignoring problems is bad.
> 3. Create a dummy EO. This is what WO does by default. See ERXDatabaseContextDelegate.databaseContextFailedToFetchObject below for why you don't see this when using Wonder:
>
> /**
> * This is Kelly Hawks' fix for the missing to one relationship.
> * Delegate on EODatabaseContext that gets called when a to-one fault cannot find its data in
> * the database. The object that is returned is a cleared fault.
> * We raise here to restore the functionality that existed prior to WebObjects 4.5.
> * Whenever a fault fails for a globalID (i.e. the object is NOT found in the database), we raise
> * an {@link com.webobjects.eoaccess.EOObjectNotAvailableException EOObjectNotAvailableException}. <br>
> * If you have entities you don't really care about, you can set the system property
> * <code>er.extensions.ERXDatabaseContextDelegate.tolerantEntityPattern</code> to a regular expression
> * that will be tested against the GID entity name. If it matches, then only an error will be logged
> * but no exception will be thrown.
> *
> * @param context database context
> * @param object object that is firing the fault for a given to-one relationship
> * @param gid global id that wasn't found in the database.
> */
> public boolean databaseContextFailedToFetchObject(EODatabaseContext context, Object object, EOGlobalID gid) {
>
>
>
>
> --
> Chuck Hill Senior Consultant / VP Development
It _is_ a Wonder project, but it may not be Wonder enough.
Creating a Wonder project does not automatically get you ERXComponent-based pages or the right kind of EOEditingContext and so on and so forth. So, yes, I should have probably set some other stuff up.
Or WOLips could give me the right thing. I guess it is not perfect. But then, neither am I.
cheers - ray
_______________________________________________
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