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

Practical WebObjects - for developers who want to increase their overall 
knowledge of WebObjects or who are trying to solve specific problems.    
http://www.global-village.net/products/practical_webobjects







Attachment: smime.p7s
Description: S/MIME cryptographic signature

 _______________________________________________
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]

Reply via email to