db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ludovic Maitre (POP - Factory Part)" <lmai...@factory-part.com>
Subject Re: [repository.dtd] class-descriptor attribute 'extends' - dispensable?
Date Fri, 08 Oct 2004 12:21:07 GMT
Hello Armin,

And thanks for your response.

Armin Waibel wrote:
...

> ok, you use an abstract base object. Are you interested in queries 
> against this base object (e.g. give all AbstractObject)? Or would you 
> like to use the abstract class as a reference in other classes (e.g. 
> Degustation declare an reference-descriptor with AbstractObject as 
> class-ref, will be possible in OJB 1.1, not supported in OJB1.0.x)?

Yes, we are interested for querying only the base object, for example 
for find all the objects which match a given field ('name' for example). 
I think (and hope since we have designed our apps with this criteria in 
head among other things) that it is more fast to query only the table 
where reside the AbstractObject fields than the 14 child objects (like 
degustation) tables. But perhaps i'm wrong.  We also want to be able to 
query only the Degustation objects who match a given field, perhaps 
declared in the super class, so we also need to reference fields from 
Degustation in base object (a priori...). We also want than we query an 
object in the abstract object's table, the complete object (with 
adequate properties filled) will be returned.

> If not, I can't imagine a reason for declaring all these objects as 
> 'extent-class' of AbstractObject. For best performance declare extents 
> only if needed. OJB does not need to know about all base classes.

It's yes.

> I assume that all sub-objects like 'Organisme', 'Degustation' share 
> the same fields and references declared in AbstractObject. The SQL 
> tables include all fields of the concrete objects (super fields and 
> specific fields for sub class) - right?.

Not exactly right, the fields of the super class are stored in another 
table than the fields of the child class.

> The only possible effect of 'extends' attribute seems that you do not 
> need to declare the super fields in the sub classes descriptors. Or do 
> I miss something?

Yes, i do not declare the fields in the sub classes descriptors. Also, 
and i think this is the most important point, the fields from the super 
class resides and are declared on another db table (the table of the 
super class).

> So, to make your classes work without 'extends' feature always declare 
> all fields (including the super fields) in the class-descriptor of the 
> sub classes (e.g. when using xdoclet this is done automatic).

As i had understand ojb for the moment, but i only have re-reread the 
manual about super-field references this morning, fields inside a class 
could only reside in the same db table. The fields of my super class are 
stored in another db table. (my read of this morning should perhaps 
solve entirely my problems!)

> If ObjetTouristiqueAbstrait object is an abstract class you don't need 
> a DB table for this object, because you never will store objects of 
> ObjetTouristiqueAbstrait (only sub objects).

But we want to do query only about this base object, often, and it seems 
to be more efficent to query only the table with the base object than 
the 14 tables of the childs objects. Also, there are more fields in the 
14 tables if we declare the fields in the child tables (so the searches 
in db are a little slower on columns without indexes?), and we must do 
our query about 14 tables. No ?

> To inform OJB about this abstract class only declare the extent classes
>
> <class-descriptor class="fr.factory.tif.ota.ObjetTouristiqueAbstrait">
> <extent-class class-ref="fr.factory.tif.ascf.ActiviteSCF"/>
> <extent-class class-ref="fr.factory.tif.deg.Degustation"/>
> <extent-class class-ref="fr.factory.tif.fma.FeteManifestation"/>
> <extent-class class-ref="fr.factory.tif.hlo.HebergementLocatif"/>
> <extent-class class-ref="fr.factory.tif.hot.Hotellerie"/>
> <extent-class class-ref="fr.factory.tif.hpa.HotelleriePleinAir"/>
> <extent-class class-ref="fr.factory.tif.iti.Itineraire"/>
> <extent-class class-ref="fr.factory.tif.loi.Loisirs"/>
> <extent-class class-ref="fr.factory.tif.mul.Multimedia"/>
> <extent-class class-ref="fr.factory.tif.org.Organisme"/>
> <extent-class class-ref="fr.factory.tif.pcu.PatrimoineCulturel"/>
> <extent-class class-ref="fr.factory.tif.pna.PatrimoineNaturel"/>
> <extent-class class-ref="fr.factory.tif.res.Restauration"/>
> <extent-class class-ref="fr.factory.tif.vil.VillageVacance"/>
> </class-descriptor>
>
> Now you can build queries against ObjetTouristiqueAbstrait and OJB 
> returns Collections containing the matching sub classes.

But the query will be done against 14 tables ? If this is right, this 
has no impacts on performance ? (i imagine, i have made no bench. You ? 
or i must do a database administrator formation/school perhaps ? (right 
i think ;-))

>> the childs objects have the attribute "extends" set to the parent 
>> object, here fr.factory.bo.AbstractObject. The childs objects/classes 
>> have obviously different properties, so they are each stored on a 
>> separate db table. Their primary key is the same than the primary key 
>> of the parent object.
>> A priori, our problems was :
>> - that OJB didn't fetch the fields for the super class natively. 
>
> yep, OJB does not import fields from the super classes automatic, you 
> have to declare all super fields in the sub classes again. But this 
> isn't a "inheritance problem", it's more a problem of reading metadata.

For this reason, i will evaluate creating my class descriptors using the 
super attribute - if it it permit to store the super fields on another 
table - IIRC that is easy, it's explained in the tutorials.
I agree that perhaps it's more efficient to manage the inheritance by 
other ways. For example by creating a PB API wrapper that when i want to 
fetch an object, populate an object with the fields of the super class 
and after populate the fields of the child class and return the result.

>
> And yes the 'extends' attribute seems to solve this problem. But I 
> think it's a bad solution, because the OJB kernel shouldn't take care 
> of super-fields, this should be handled when reading the metadata, 
> e.g. by automatic copying super fields to the sub classes 
> ClassDescriptor.
>
I agree with you, my only problem is that i haven't succeeded for the 
moment - but i will test by using the super reference descriptor - to 
use objects with super-fields stored in another table.

>> We have do a patch for this, which most notably use 
>> getFieldsInHierarchy for obtain all the fields to retrieve.
>> - the same for the references and collection IIRC, we have also to 
>> some patch for this.
>> but perhaps we are on the wrong way...
>> But i'm not really clear in my explanations** so i suggest that you 
>> look at some samples metadata (commons-sql xml descriptor, generated 
>> sql-ddl, ojb class descriptor, for a parent and a child object) at 
>> the following page :
>> http://dev.factory-part.com/oss/ojb/samples/objects.html
>>
>
> Thanks for the effort! Hope my notes are helpful.
>
> regards,
> Armin

Thanks for your time Armin, if our approach is useful we fill do the 
necessary to made a (clean) port (with testcases) of theses patch for 
OJB 1.1. But you must evaluate and confirm, or other peoples in the 
mailing list, that our approach is valid (that it's not a so bad 
design), we haven't a lot of experience in this area....

Regards,
Ludo


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