Mailing-List: contact ojb-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "OJB Developers List" <ojb-dev@db.apache.org>
Message-ID: <3F8E7C4A.3000409@gmx.ch>
Date: Thu, 16 Oct 2003 13:08:58 +0200
From: Jakob Braeuchi <jbraeuchi@gmx.ch>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.4.1) Gecko/20031008
MIME-Version: 1.0
To: Brendan Boesen <brendan.boesen@hesageek.com.au>
CC: Brian McCallister <mccallister@forthillcompany.com>,
 OJB Developers List <ojb-dev@db.apache.org>
Subject: Re: OJB extents problems
References: <000901c38706$206465f0$440c0aa2@frogboy> <3F79D84B.9010305@gmx.ch>
 <007001c38c95$71435640$440c0aa2@frogboy> <3F8277A2.1020906@gmx.ch>
 <002701c38d4f$f7e700b0$440c0aa2@frogboy> <3F842D76.3030602@gmx.ch>
 <003501c38e11$92162960$440c0aa2@frogboy> <3F85240C.3060703@gmx.ch>
 <008201c3906b$3d6d9cc0$440c0aa2@frogboy> <3F891014.9060808@gmx.ch>
 <00b001c392d5$1a62ae70$440c0aa2@frogboy> <3F8D53EA.9060207@gmx.ch>
 <00ce01c3939f$fe7c7bc0$440c0aa2@frogboy>
In-Reply-To: <00ce01c3939f$fe7c7bc0$440c0aa2@frogboy>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

hi brendan,

Brendan Boesen wrote:

> Jakob,
> 
> 
>>imo you should not query for the super-classes ! the anonymous
> 
> 
> Ok, that's fine, but it is not the way the tutorial is written.
> 
> To quote:
> 
> "OJB allows [sic] to use interfaces or (possibly abstract) baseclasses in
> queries or in type definitions of reference attributes.  A Query against the
> interface InterfaceArticle must not only return objects of type Article but
> also of CdArticle and Book Article !"
> 
> and further on:
> 
> "The query in the last example returned just one object.  Now imagine a
> query against InterfaceArticle with no selecting criteris.  What do you
> expect to happen?
> Right: OJB returns ALL objects implementing InterfaceArticle.  I.e. All
> Articles, BookArticles and CdArticles.  The following method prints out the
> collection of all InterfaceArticle objects."
> 
> The tutorial mentions that "The set of all instances of a class (whether
> living in memory or stored in a persistent medium) is called Extent in ODMG
> and JDO terminology."  I haven't had a chance to look this up yet but if
> this is the ODMG/JDO definition, and OJB provides interfaces compliant with
> these standards, then surely I SHOULD be able to do what I expected to do,
> ie: query for all objects of type E and get back a collection containing all

yup, this is possible for 'normally' mapped objects. you'll get a select 
for each extent.

> objects of types F and F1 and consequently all objects of type G and G1.  Of
> course, to do this I would have to define an extent for E to include F, F1,
> G and G1 BUT extent is broken with F1 and G1!

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.

> 
> Jakob, I really appreciate the time you have put into answering my queries
> and hope you will have just a little more patience in helping me get to the
> bottom of all this.  Thanks!

well, my holydays are going to end this week...

jakob

> 
> Brendan
> 
> 
> 
>>hth
>>jakob
>>
>>Brendan Boesen wrote:
>>
>>
>>>Jakob,
>>>
>>>I'm still a little confused.
>>>
>>>Please bear with me as I rework my example using the standard test
> 
> classes
> 
>>>(E, F, G, F1, G1).
>>>
>>>Class Structure:
>>>----------------
>>>
>>>G --subclasses--> F --subclasses--> E
>>>G1 --subclasses--> F1 --subclasses--> E
>>>
>>>
>>>Database Structure:
>>>--------------------
>>>
>>>TABLE_E
>>>  unique ID,
>>>  someSuperValue.
>>>
>>>TABLE_F
>>>  unique ID,
>>>  someValue,
>>>  anonymous foreign key linked to TABLE_E.ID
>>>
>>>TABLE_G
>>>  unique ID,
>>>  someSubValue,
>>>  anonymous foreign key linked to TABLE_F.ID
>>>
>>>TABLE_F1
>>>  unique ID but value taken from TABLE_E.ID,
>>>  someValue
>>>
>>>TABLE_G1
>>>  unique ID but value taken from TABLE_F1.ID,
>>>  someSubValue,
>>>
>>>Sample Database Values:
>>>--------------------------
>>>
>>>Here are the database values for 4 objects (f, g, f1 and g1) with the
>>>following values:
>>>f: someSuperValue = 1, someValue = 2
>>>g: someSuperValue = 3, someValue = 4, someSubValue = 5
>>>f1: someSuperValue = 6, someValue = 7
>>>g1: someSuperValue = 8, someValue = 9, someSubValue = 10
>>>
>>>SQL> select * from table_g1;
>>>
>>>        ID SOMESUBVALUE
>>>---------- ------------
>>>       397           10
>>>
>>>SQL> select * from table_f1;
>>>
>>>        ID  SOMEVALUE
>>>---------- ----------
>>>       396          7
>>>       397          9
>>>
>>>SQL> select * from table_g;
>>>
>>>        ID       F_ID SOMESUBVALUE
>>>---------- ---------- ------------
>>>       366        392            5
>>>
>>>SQL> select * from table_f;
>>>
>>>        ID       E_ID  SOMEVALUE
>>>---------- ---------- ----------
>>>       391        394          2
>>>       392        395          4
>>>
>>>SQL> select * from table_e;
>>>
>>>        ID SOMESUPERVALUE
>>>---------- --------------
>>>       396              6
>>>       397              8
>>>       394              1
>>>       395              3
>>>
>>>Here are some queries using OJB and their results:
>>>
>>>broker.getCollectionByQuery(new
> 
> QueryByCriteria(ObjectRepository.G.class)):
> 
>>>    instance of G with: someSuperValue = 3, someValue = 4, someSubValue
> 
> = 5
> 
>>>ie: object g above
>>>
>>>broker.getCollectionByQuery(new
> 
> QueryByCriteria(ObjectRepository.G1.class)):
> 
>>>    instance of G with: someSuperValue = 8, someValue = 9, someSubValue
> 
> = 10
> 
>>>ie: object g1 above
>>>
>>>broker.getCollectionByQuery(new
> 
> QueryByCriteria(ObjectRepository.F.class)):
> 
>>>    instance of F with: someSuperValue = 1, someValue = 2    ie: object
> 
> f
> 
>>>above
>>>    instance of F with: someSuperValue = 3, someValue = 4    ie: object
> 
> g
> 
>>>above but of wrong class!
>>>
>>>broker.getCollectionByQuery(new
> 
> QueryByCriteria(ObjectRepository.F1.class)):
> 
>>>    instance of F1 with: someSuperValue = 6, someValue = 7    ie: object
> 
> f1
> 
>>>above
>>>    instance of F1 with: someSuperValue = 8, someValue = 9    ie: object
> 
> g1
> 
>>>above but of wrong class!
>>>
>>>broker.getCollectionByQuery(new
> 
> QueryByCriteria(ObjectRepository.E.class)):
> 
>>>    instance of E with: someSuperValue = 1    ie: object f above  but of
>>>wrong class!
>>>    instance of E with: someSuperValue = 3    ie: object g above but of
>>>wrong class!
>>>    instance of E with: someSuperValue = 6    ie: object f1 above  but
> 
> of
> 
>>>wrong class!
>>>    instance of E with: someSuperValue = 8    ie: object g1 above but of
>>>wrong class!
>>>
>>>Now, give then way the xml metadata and the table structures are
> 
> defined,
> 
>>>the above results are understandable.  They are also, however, of
> 
> debatable
> 
>>>usefulness!  The results of the query against ObjectRepository.E.class
> 
> do
> 
>>>not represent any real objects that were created in the system.
>>>
>>>I thought the use of extent would have allowed me to define the
> 
> inheritance
> 
>>>hierarchy in such a way that
>>>
>>>broker.getCollectionByQuery(new
>>>QueryByCriteria(ObjectRepository.G.class)): --> g
>>>broker.getCollectionByQuery(new
>>>QueryByCriteria(ObjectRepository.G1.class)): --> g1
>>>broker.getCollectionByQuery(new
>>>QueryByCriteria(ObjectRepository.F.class)): --> f, g
>>>broker.getCollectionByQuery(new
>>>QueryByCriteria(ObjectRepository.F1.class)): --> f1, g1
>>>broker.getCollectionByQuery(new
>>>QueryByCriteria(ObjectRepository.E.class)): --> f, g, f1, g1
>>>
>>>I suspect I have misunderstood what the extent tag was supposed to
> 
> provide.
> 
>>>
>>>Brendan
>>>
>>>
>>>
>>>
>>
>>
> 
> 


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