Hey Armin! Thanks a lot for registering this as a bug. It's been noted as a "known issue" in the release notes for a while, but it really *was* a bug.
Let's see if this gets the deserved attention from now on. I'll see what I can do to help and will let you know if I make any progress. Regards, Luis. De:"Armin Waibel (JIRA)" [EMAIL PROTECTED] Para:[email protected] Cópia: Data:Sun, 7 Aug 2005 02:08:35 +0200 (CEST) Assunto:[jira] Created: (OJB-63) Bug when query against objects mapped on multiple joined tables ("super"-references) > Bug when query against objects mapped on multiple joined tables > ("super"-references) > ------------------------------------------------------------------------------------ > > Key: OJB-63 > URL: http://issues.apache.org/jira/browse/OJB-63 > Project: OJB > Type: Bug > Components: JDO-API, ODMG-API, OTM-API, PB-API > Versions: 1.0.3 > Reporter: Armin Waibel > Priority: Critical > > > When query against a class mapped on multiple joined tables (using > "super"-references) or using such a class in a reference only objects of the > base type class will be instantiated. > Example: > > Employee<--Manager<--Shareholder > > Criteria crit = new Criteria(); > Query query = QueryFactory.newQuery(Employee.class, crit); > Collection result = broker.getCollectionByQuery(query); > > Collection result only contains objects of type 'Employee' (the base class) > even if the real type was Manager or Shareholder. > > See in OJB test suite > ...broker.InheritanceMultipleTableTest#testInheritancedObjectsInCollectionReferences. > > The problem is how OJB is building the join when using super-references > ("super" keyword in reference-descriptor). > In SqlQueryStatement there is no specific handling for queries against > classes mapped on multiple joined tables, thus always instances of the > query class (e.g. Employee) are returned instead of the real > sub-classes (e.g. Employee, Manager, ...). > > A solution for this issue is to use sql-case > expressions to build the join: > (e.g. Manager and Customer are sub-classes of Employee) > > select > person0_.person_id as person1_, > ... > person0_1_.title as title1_, > ... > person0_2_.bio as bio2_, > person0_3_.comments as comments3_, > person0_3_.salesperson as salesper3_3_, > case > when person0_2_.person_id is not null then 2 > when person0_1_.person_id is not null then 1 > when person0_3_.person_id is not null then 3 > when person0_.person_id is not null then 0 > end as clazz_ > from Person person0_ > left outer join Employee person0_1_ on > person0_.person_id=person0_1_.person_id > left outer join Manager person0_2_ on > person0_.person_id=person0_2_.person_id > left outer join Customer person0_3_ on > person0_.person_id=person0_3_.person_id > where (person0_2_.bio='my bio') > > Now the application can decide which class to instantiate by evaluating the > "clazz_" column in the ResultSet. This is the missing part in OJB (need > improvements in org.apache.ojb.broker.accesslayer.sql.* classes and > RsIterator). > > -- > This message is automatically generated by JIRA. > - > If you think it was sent incorrectly contact one of the administrators: > http://issues.apache.org/jira/secure/Administrators.jspa > - > For more information on JIRA, see: > http://www.atlassian.com/software/jira > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > ! --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
