db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakob Braeuchi <jbraeu...@gmx.ch>
Subject Re: Extents and the various inheritance hierarchy mappings
Date Thu, 23 Oct 2003 17:25:47 GMT
hi brendan, brian,

ojb should _not_ produce duplicates.

i query for all kinds of articles with id > 70:

         query(CdArticle.class, broker);
         query(BookArticle.class, broker);
         query(Article.class, broker);
         query(AbstractArticle.class, broker);
         query(InterfaceArticle.class, broker);

the cache is cleared before executing the query.

the problem is visible when querying for interfaceArticle. the first 3 
queries are ok but there are two additionl selects for books and cds. 
these selects produce the duplictes.

SELECT ... FROM Artikel A0 WHERE A0.Artikel_Nr >  '70'
SELECT ... FROM BOOKS A0 WHERE A0.Artikel_Nr >  '70'
SELECT ... FROM CDS A0 WHERE A0.Artikel_Nr >  '70'
SELECT ... FROM BOOKS A0 WHERE A0.Artikel_Nr >  '70'
SELECT ... FROM CDS A0 WHERE A0.Artikel_Nr >  '70'

i'm investigating this problem.

the other problem (wrong class instantiated) is caused by duplicate 
primary keys within a hierarchy. ojb requires the pk to be _unique_ 
within the hierachy. otherwise getObjectByIdentity could return multiple 
objects.

jakob




Brendan wrote:
> 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
> 
> 


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