You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-dev@db.apache.org by "Jakob Braeuchi (JIRA)" <ji...@apache.org> on 2005/10/10 20:26:52 UTC
[jira] Assigned: (OJB-63) Bug when query against objects mapped on multiple joined tables ("super"-references)
[ http://issues.apache.org/jira/browse/OJB-63?page=all ]
Jakob Braeuchi reassigned OJB-63:
---------------------------------
Assign To: Jakob Braeuchi
> 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, 1.0.x CVS, 1.1 CVS
> Reporter: Armin Waibel
> Assignee: Jakob Braeuchi
> Priority: Critical
> Fix For: 1.0.4, 1.1 CVS
>
> 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: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org