db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brendan Boesen" <bboe...@tpg.com.au>
Subject Extents and the various inheritance hierarchy mappings
Date Mon, 20 Oct 2003 00:18:06 GMT
Hi All,

Jakob and I have been having a back and forth discussion on the use of
extents and the different inheritance hierarchy mappings.  He has suggested
I move this discussion up onto the dev list.  The discussion has a bit of
history but most of that is summarised in this post.

[ The following quote is from Jakob's last reply to me, which he posted to
the list as message 5975. ]

>
> that's right you'll have to use extents to obtain this behaviour.
> BUT these super-classes in the testcase are imo only _technical_ classes
> to map a single object (G1) onto multiple tables. i'd prefer a solution
> where each class is mapped to a single table, if this is possible in
> your case. and then define the extents, like the testcase-classes
> Article, CD, Books etc.
>

The issue of what is a good (or not) database mapping structure is very much
specific to the problem at hand.  I assume it is a design goal of OJB to
support a variety of mappings and to support extents with all (or at least
most) of these mappings.  (If that assumption is wrong, the rest of this
discussion is mute!  :-)

As the tutorial describes, there are four solutions for mapping the
inheritance hierarchy E, F and G:
1) Combined table for super-class and subclasses
2) Separate tables for 'concrete' subclasses.
3) Separate tables for super-class and subclasses, with two variations:
    3.1) Subclass uses separate id and a foreign key to link to parent class
    3.2) Subclass uses a common id and foreign key

The Article, BookArticle and CdArticle classes are examples of 2).  The
classes E, F, G are examples of 3.1) and E, F1, G1 are examples of 3.2).
(There must be classes in the test cases that show 1) but I haven't tried
out extents with them.)

The query against base classes works (almost) as I'd expect with the
Article, BookArticle and CdArticle classes.  I say almost because I do get
back duplicate results for a query against InterfaceArticle.  A little
unexpected but it doesn't matter too much.  If I create one instance each of
CdArticle, BookArticle and Article and do class-based queries I get:

new ArrayList(broker.getCollectionByQuery(new
QueryByCriteria(CdArticle.class))) = ArrayList  (id=61)
 elementData= Object[1]  (id=62)
  [0]= CdArticle  (id=65)
 modCount= 0
 size= 1

new ArrayList(broker.getCollectionByQuery(new
QueryByCriteria(BookArticle.class))) = ArrayList  (id=73)
 elementData= Object[1]  (id=74)
  [0]= BookArticle  (id=77)
 modCount= 0
 size= 1

new ArrayList(broker.getCollectionByQuery(new
QueryByCriteria(Article.class))) = ArrayList  (id=85)
 elementData= Object[3]  (id=86)
  [0]= $Proxy0  (id=89)                        [ The Proxy is a proxy for
the Article instance. ]
  [1]= BookArticle  (id=92)
  [2]= CdArticle  (id=93)
 modCount= 0
 size= 3

new ArrayList(broker.getCollectionByQuery(new
QueryByCriteria(InterfaceArticle.class))) = ArrayList  (id=101)
 elementData= Object[5]  (id=102)
  [0]= $Proxy0  (id=105)                        [ The Proxy is a proxy for
the Article instance. ]
  [1]= BookArticle  (id=106)
  [2]= CdArticle  (id=107)
  [3]= BookArticle  (id=106)
  [4]= CdArticle  (id=107)
 modCount= 0
 size= 5

If I try a similar query against the E <|--- F <|--- G inheritance hierarchy
I get slightly weirder results.

First, I added the following extent clauses:

 <class-descriptor
        class="org.apache.ojb.broker.ObjectRepository$E"
        table="TABLE_E">

    <extent-class class-ref="org.apache.ojb.broker.ObjectRepository$F" />

    ETC.

 <class-descriptor
        class="org.apache.ojb.broker.ObjectRepository$F"
        table="TABLE_F">

    <extent-class class-ref="org.apache.ojb.broker.ObjectRepository$G" />

Then, I created the following instances:
    f: someSuperValue = 1, someValue = 2
    g: someSuperValue = 3, someValue = 4, someSubValue = 5

The query results are then:

new ArrayList(broker.getCollectionByQuery(new
QueryByCriteria(ObjectRepository.G.class)) = ArrayList  (id=77)
 elementData= Object[1]  (id=78)
  [0]= ObjectRepository$G  (id=95)
   id= 1071
   someSubValue= 5
   someSuperValue= 3
   someValue= 4
 modCount= 0
 size= 1

new ArrayList(broker.getCollectionByQuery(new
QueryByCriteria(ObjectRepository.F.class)) = ArrayList  (id=84)
 elementData= Object[3]  (id=86)
  [0]= ObjectRepository$F  (id=96)
   id= 1069
   someSuperValue= 1
   someValue= 2
  [1]= ObjectRepository$F  (id=97)                       [ mutant g ]
   id= 1072
   someSuperValue= 3
   someValue= 4
  [2]= ObjectRepository$G  (id=95)
   id= 1071
   someSubValue= 5
   someSuperValue= 3
   someValue= 4
 modCount= 0
 size= 3

new ArrayList(broker.getCollectionByQuery(new
QueryByCriteria(ObjectRepository.E.class)) = ArrayList  (id=91)
 elementData= Object[5]  (id=92)
  [0]= ObjectRepository$E  (id=98)                       [ mega-mutant f ]
   id= 1070
   someSuperValue= 1
  [1]= ObjectRepository$E  (id=99)                       [ mega-mutant g ]
   id= 1073
   someSuperValue= 3
  [2]= ObjectRepository$F  (id=96)
   id= 1069
   someSuperValue= 1
   someValue= 2
  [3]= ObjectRepository$F  (id=97)                       [ mutant g ]
   id= 1072
   someSuperValue= 3
   someValue= 4
  [4]= ObjectRepository$G  (id=95)
   id= 1071
   someSubValue= 5
   someSuperValue= 3
   someValue= 4
 modCount= 0
 size= 5

The query against G returns the right result, ie: the instance g.  The query
against F returns both f and g, as expected, but also returns an instance
'mutant-g' (of type F) that never existed in the first place!  The query
against E returns both f and g, as expected, but also returns a couple of
mega-mutants for f and g (of type E) and the not-so-mega-mutant-g (of type
F), none of which ever existed in the first place!

Is this really the expected behaviour?

If the answer is no then I should also be able to set up similar extents for
the E <|---F1 <|--- G1 hierarchy but using extent clauses with these classes
is broken.  [ This last statement, and its justification, is a part of
Jakob's and my discussions that isn't recorded in this post. It can easily
be verified by adding extent clauses to E and F1 and watching some of the
AnonymousFieldsTest fail. ]


Brendan


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


Mime
View raw message