Re: EOKeyValueQualifier not resolving vertical inheritance?
Re: EOKeyValueQualifier not resolving vertical inheritance?
- Subject: Re: EOKeyValueQualifier not resolving vertical inheritance?
- From: Wolfram Stebel <email@hidden>
- Date: Wed, 15 Mar 2006 12:33:32 +0100
- Thread-topic: EOKeyValueQualifier not resolving vertical inheritance?
Am 14.03.2006 14:18 Uhr schrieb "Kieran Kelleher" unter
<email@hidden>:
Hello Kieran,
> I had issues with EOQualifiers and inheritance hierarchies generating
> bad SQL a few weeks ago and the solution (Chuck Hill responded I think)
> was to stick with single table inheritance if you want reliable SQL
> generated from your EOQualifiers.
This is not a too good advice for a productive application...
Shouldn't WO use EOQualifiers in producing it's own fetches, that work well
with vertical inheritance?
Thanks anyway :-)
Wolfram
>> i create a complex query from user input via EOKeyValueQualifier and
>> other
>> EOQualifiers.
>>
>> Absolutely fine is:
>> EOKeyValueQualifier ( myAttributeName, mySelector, myComparedEO );
>>
>> Also OK is it for a keypath to a non flattened attribute (lets say:
>> "location.derivedClassAttribute", where location is a derived class):
>> EOKeyValueQualifier ( "location.derivedClassAttribute", mySelector,
>> myComparedValue );
>> (myComparedValue is a string in this case).
>>
>> The above statement creates joins with aliases like:
>>
>> ...FetchedClass t0, Location T1, LocationBaseClass T2...
>>
>> and fetches the correct EOs.
>>
>> When the left hand side points to an attribute of an inherited class it
>> evaluates to the wrong derived entity:
>> Compared to the above example:
>> EOKeyValueQualifier ( "location.baseClassAttribute", mySelector,
>> myComparedValue );
>> does not evaluate to table "Location". Instead it creates aliases like:
>>
>> ... FetchedClass t0, Person T1, LocationBaseClass T2...
>>
>> where "Person" is another derived class of the same base class.
>>
>> This seems to be a bug, because the class information for
>> "location.baseClassAttribute" is available and correct for the relation
>> "location", but it does not create the correct SQL.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden