you can manually address this with EODatabaseContext Delegate if you really
wanted to, though I think the real problem is that you don't have referential
integrity constraints on your database, which should have failed on import
rather than on fetch ...
/**
* Invoked when a to-one fault cannot find its data in the
database.
* <code>object</code> is a cleared fault identified by the
globalID
* <code>gid</code>. If this method returns <code>true</code>,
* <code>dbCtxt</code> assumes that the delegate set the
information
* into the object, and created a snapshot of it, correcting the
* problem.
* <p>
* If the delegate returns <code>false</code> or if the
delegate method
* is not implemented, <code>dbCtxt</code> tracks the
<code>gid</code>
* of the offending object. If the tracked <code>gid</code> is
in the
* list of updated objects when changes to the editing context
are
* saved, the database context throws an exception. The method
* <code>missingObjectGlobalIDs</code> can be used to get a
list of
* objects that failed to fetch.
* </p>
*
* @param dbCtxt
* The database context.
* @param object
* A cleared fault.
* @param gid
* The globalID that identifies <code>object</code>.
* @return Should return <code>true</code> if the faulting
problem has
* been handled, <code>false</code> otherwise.
* @see #missingObjectGlobalIDs()
* @see #prepareForSaveWithCoordinator(EOObjectStoreCoordinator
* coordinator, EOEditingContext editingContext)
*/
public boolean
databaseContextFailedToFetchObject(EODatabaseContext dbCtxt, Object object,
EOGlobalID gid);
On Jan 14, 2011, at 12:14 PM, 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?
>
> - 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/mschrag%40pobox.com
>
> This email sent to [email protected]
_______________________________________________
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]
