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 protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
