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