Mailing-List: contact ojb-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "OJB Developers List" <ojb-dev@db.apache.org>
Date: Thu, 23 Oct 2003 13:41:25 +1000
Subject: Re: Extents and the various inheritance hierarchy mappings
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
From: Brendan <bboesen@tpg.com.au>
To: "OJB Developers List" <ojb-dev@db.apache.org>
Content-Transfer-Encoding: 7bit
In-Reply-To: <454173C6-04F3-11D8-83A8-000A95782782@forthillcompany.com>
Message-Id: <C74C2CF7-050A-11D8-9EED-00039388635E@tpg.com.au>

Jakob's and my discussions have stalled a little, due both to the end 
of his holidays and some unanswered questions over what OJB's behaviour 
should be (which were documented in my last post).

If it IS the official position that OJB should not be producing 
duplicates and mutants from extent queries then I'm more than happy to 
look into it a little further.  The only caveat is that my time is also 
somewhat limited (usual story!).

Brendan


On Thursday, October 23, 2003, at 10:53 AM, Brian McCallister wrote:

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


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