Re: Strange error message

Hi Pierre,

thanks for the exhaustive note. I'm still not sure why this wouldn't 
affect to-many relationships or how to work around this in a more 
general fashion.

> A cleaner solution that implies more work is not to define the 
> inheritence in EOModeler but only in your classes. I.e. you would 
> manually create the common abstract parent class. This approach has 
> the advantage of effectively prebenting offenting relationships to be 
> created.

I'm not sure what you mean: if I don't model the inheritance, would I 
include Vehicle in my model? If I don't, then how could I have a 
relationship to it? You don't happen to have a working example handy ?-)



Am Mittwoch, 09.10.02, um 16:21 Uhr (Europe/Berlin) schrieb Pierre 
Bernard:

> Hi!
>
>> Sorry, but to me this sounds like a bug: it means you can't have 
>> legacy
>> databases which have horizontal inheritance and a common set of PKs -
>> which sounds like a pretty severe restriction to me.
>>
>> Also, I see no reason why the GlobalID should contain the root entity
>> and not the actual one.
>
> I am jumping into this discussion not knowing what has been said yet.
>
> The main catch is that you might want to have to-one relationships to 
> an entity which has children. E.g. The abstract entity Vehicle has two 
> concrete implementations: Bicycle and Car. A Person object has one 
> Vehicle. In that situation EOF creates a fault for the to-one 
> relationship. That fault is identified by a global ID that references 
> the destination entity of the relationship (Vehicle in the example). 
> Only when the fault is tripped EOF tries to figure out which concrete 
> entity is at the end of that relationship. For that it will query both 
> the Bicycle and Car tables with the primary key found in the fault's 
> globalID. It will use the first matching record. Thus IDs need to be 
> unique. As a side effect, if you already had an EO in the editing 
> context that matched the globalID that one would get used. This could 
> lead to seemingly random errors where depending on what was fetched 
> previously one or the other of the possible concrete instances is > used.
>
> In the case of legacy databases you may work around this restrictions 
> if you no for sure that you don't have (and never will have) to-one 
> relationships to the root entity, but only to leaf entities.
> In that event you can define the inheritence in your EOModel and have 
> the classes generated appropriately, but then programatically break 
> the inheritence at model load time.
>
> A cleaner solution that implies more work is not to define the 
> inheritence in EOModeler but only in your classes. I.e. you would 
> manually create the common abstract parent class. This approach has 
> the advantage of effectively prebenting offenting relationships to be 
> created.
>
> Caveat: WO 5.1 has made changes to how to-one realtionships to 
> abstract entities are handled. It seems to me that those faults are 
> immediately tripped. I have not looked into this in detail and don't 
> know if or how it influences the above.
>
> Pierre.
>
>
>
>
Cheers, Anjo