I stumbled across this issue yesterday and thought that some of you
may find it interesting (if you didn't know about it already). Maybe
there's a design idiom I'm missing.
I have a abstract parent class entity A and another entity B joined
like A <--->> B
A subclasses use single table inheritance with a field called docType
to act as the restricting qualifier.
A has concrete subclass entites AB and AC. I can traverse toB and
get it's objects. B objects can also create a fault for toA and
resolve the fault to either AB or AC based on the foreign key.
However, if AB.toB has batch faulting specified, EOF returns the
error: key '_eofInv_AB_toB.docType' was not reachable from from
entity 'B' . Indeed, there is no inverse of toB from AB since the
inverse points to A, not AB.
I believe that when batch faulting the B records, it further
constrains the B records to those at the end of AB.toB. In order to
do that it needs the restricting qualifier to get those that belong
to AB. Since it can't resolve the join to AB, it throws the error.
By creating a relationship from B to AB and not making it a class
property, the request does not fail.
This really isn't an answer, however, since the relationship from B
to AB has a foreign key belonging to A (as it is originally
designated in A<-->>B), it is not true that the foreign key always
belongs to AB. In this example, the key could belong to AC. If the
problem is resolved for AC by adding a relationship path to AC, then
the model has a foreign key that belongs to two distinct subsets of
A. Namely, AB and AC. This is impossible.
My gut reaction is to eliminate the batch faulting and not pursue the
bogus relationship method to provide inverse relationships. If there
is anything that I have learned in WebObjects it is that the EO model
has to be exactly perfect or even if something works for a while, it
will eventually break. Besides, this is clearly not right.
Lastly, I guess my question is that since the definition toB is
required for every subclass of A, shouldn't the inverse be
"magically" resolved since it cannot explicitly exist without fouling
the model? Hmm.
John
_______________________________________________
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]
