db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Dudziak <to...@first.fhg.de>
Subject Re: Referencing an abstract class. The next turn...
Date Tue, 12 Oct 2004 12:29:52 GMT
Carsten Spräner_Ext wrote:

>Hi Tom,
>thank you for your Tip. I first answered the mail from armin an than i read
>your mail. Sorry. But the problem is still not solved:
>1. Having COL_ID in B and in the repository does mean having it in TABLE_B.
>Doesn't it? If yes, this is not a solution.
Then you have to use multiple-joined tables, i.e. the super-reference 
and the superID field without the <extent-class>.

>2. Yes i can load instances of B when i directly query a class B. But when
>loading a collection i do not know the concrete class. If i don't use the
>ojbConcreteClass feature how should OJB know which class to load?
>The test program loads instances of B if i directly query for B. But it
>does not load B if i create the query with A.class as parameter. I think
>the code loding the collection has the same problem.
>But your tip solved the problem, that there are some doublicated entries.
>Thanks for that. But what about the other problem? I think that's what
>armin said.
Hmm, I'm no expert when it comes to mapping classes to multiple-joined 
tables, especially when using them as elements of collections, but it 
should work when the primarykeys are unique within the hierarchy. You 
can certainly try the ojbConcreteClass thingie, which I guess it has to 
be defined in db.A.
Perhaps Armin or Jakob can shed some more light on this ?


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

View raw message