db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian McCallister <mccallis...@forthillcompany.com>
Subject Re: Extents and the various inheritance hierarchy mappings
Date Thu, 23 Oct 2003 00:53:09 GMT
Reading this over - it is definitely *not* the desired behavior, IMHO, 
to get A) duplicates or B) mutants. I am not very familiar with the 
mechanics of how extents are mapped so cannot contribute much insight.

I get the impression that Jakob is looking into it with you (?). If now 
that his holidays are up he lacks time I can learn how it is done, but 
I have a lot of already-much-later-than-I-wanted documentation to 
finish that I feel obligated to finish that up before tackling any more 
fun stuff.

Have you delved into what OJB is specifically doing for the extent 
mapping at all?

-Brian

On Sunday, October 19, 2003, at 08:18 PM, Brendan Boesen wrote:

> 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
>
>


---------------------------------------------------------------------
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