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 19:19:52 GMT
hi,

the problem with the duplicates is solved. please get the latest from 
repository (RsIterator, ChainingIterator, PersistenceBrokerImpl)

jakob

Jakob Braeuchi wrote:

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


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