db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Armin Waibel <arm...@apache.org>
Subject Re: Known issue with extents mapped to multiple tables?
Date Tue, 02 Aug 2005 09:24:22 GMT
Hi Luis,

I completely agree with you, it's hard to believe that this is is still
not working properly. This issue the most important one to "complete"
OJB 1.0.x.

Several tests are added to OJB test-suite to show the problem
(InheritanceMultipleTableTest). I started evaluating the problem, but
I'm not a sql-expert. Jakob wrote the most classes of OJB's query part
and he is the sql-expert, but he was very busy during the past few
months, currently he is on vacation (till 08/15).

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, ...).

Hibernate has a really smart solution for this problem, it use sql-case
expressions to build the join:
(Manager and Customer are sub-classes of Employee)

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_,
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
left outer join Manager person0_2_ on
left outer join Customer person0_3_ on
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).

Another problem is the correct handling of 1:n references, when the 
FK-field is declared in the super-classes (e.g. 'Consortium' has a 1:n 
to Manager but the FK to Consortium is declared in Employee, more detail 
see InheritanceMultipleTableTest#testInheritedReferences()).

Any help on this issue is welcome.


Luis Fernando Pollo wrote:
> Hello all!
> Is anyone working on the known issue with extents being mapped to 
> multiple joined tables, where queries on the base class or even 
> collection references always return instances of the base class, and not 
> of specific subclasses? Even better, has anyone patched OJB to do this 
> successfully yet?
> I've been a user of OJB since RC3, and it's hard to believe that such an 
> important part of an ORM solution is *still* not working properly in 
> 1.0.3! I've recently wandered about Hibernate-land to compare it against 
> OJB and gave up after many painful hours of object life-cycle management 
> hell, which you never have to worry about in OJB. But I have to say that 
> their support for inheritance in *any* scenario is light-years ahead... :(
> I'm hoping someone has already come up with a solution for this, because 
> it might very well be the only feature keeping me from happily switching 
> back to OJB at this point.
> Regards,
> Luis.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org

To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org

View raw message