On Jan 14, 2011, at 2:39 PM, Ray Kiddy wrote:

> 
> 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.


>> Right now, one gets an exception, something like "no eo1 object found for pk 
>> 4".

Sounds to me like Wonder IS working.  (3) is what happens if you don't use 
Wonder.


Chuck

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