Hi Wolfram,
Actually it was Neale Patton, not Chuck, who pointed this out:
http://lists.apple.com/archives/webobjects-dev/2006/Feb/msg00206.html
and the problem was incorrect SQL generation for horizontal
mapping...., not vertical ..... the release notes indicated
single-table mapping as a workaround
http://developer.apple.com/documentation/WebObjects/ReleaseNotes/
ErteRelNotes/chapter_1_section_8.html
If it is a bug, you may have to workaround with a different inheritance
mapping or custom SQL. Let us know how it works out.
Regards, Kieran
On Mar 15, 2006, at 6:33 AM, Wolfram Stebel wrote:
Am 14.03.2006 14:18 Uhr schrieb "Kieran Kelleher" unter
<[EMAIL PROTECTED]>:
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 protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
