db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Armin Waibel <arm...@apache.org>
Subject Re: [OJB] Issue #OJB292 modified
Date Thu, 23 Sep 2004 09:17:06 GMT
Hi Ludovic,

Ludovic Maitre (POP - Factory Part) wrote:
> Hello Armin,
> I will test the approach of copying field from inherited class/table 
> into children class descriptor, and see if this require less patchs than 
> our current implementation, i want to have the less patchs possible to 
> maintain.

I'm not sure that this solution will need less LOC's than your patches, 
but this way the inheritance will be encapsulated by the metadata 
classes and xml-mapping files.
To concretize the meaning of "inheritance" in this context, it only 
means that you will inherit the fields of the super-class, no automatic 
relationship between the super and sub class will be provided, e.g. 
query the super-class will NOT return all sub-classes too.
If such a behavior is needed, have a look at

> As i understand this, this is not easy to map a class on 
> multiple tables (but i must read the code again). But perhaps it's not 
> the good way to store parent and child fields in two separate DB tables, 
> as we do,

This can be done using "Mapping Classes on Multiple Joined Tables" (link 
is above).

> although the requirements of my business domain seems to 
> indicate this for some objects (for some other objects on our domain, we 
> handle inheritance by replicating fields of the parent object in the 
> child object (and storing all these fields in the same table [one per 
> type of child object]), but this is off-topic.

This should be possible using "extents" (see link above) and if all 
classes mapped to the same DB-table using the "ojbConcreteClass" feature


Recommend to write unit-tests for testing and performance tests when 
using this features for large hierarchies, e.g using "extent" for 20 or 
more classes (Animal->Dog1, Dog2, ...), because OJB have to do some 
extra queries in some cases.

> For now Ojb work for us 
> with the patchs, although this is not enough tested, so we will maintain 
> this version. If my team and me know more the code of Ojb, we could use 
> Ojb more efficiently in the future and achieve the same goals that 
> actually without modifying the code, i hope this.

Currently we working on the first alpha-version for OJB 1.1, so it will 
be possible to take in new features and changes. So all suggestions are 

> You write that the part of the code related to the "extend" attribute is 
> not actively maintained/used, so i understand why i must do so many 
> patchs (without knowing all the consequence that this produce).

sorry about that!

> Also i 
> admit that i have take the most "easy" (at first sight) way by patching 
> the low-level API.

If it works for you... it's open source ;-)

> For the patch on QueryReferenceBroker#retrieveReference, i must think 
> again about it, if i remember i have done this essentially because i 
> have problems with identity when beginning to add inheritance support, 
> and because i'm naïve and want to go faster without understanding all 
> the code (i.e set refresh="false").

No problem, I'm working on OJB for years now and don't understand the 
code ;-)
The performance of OJB when doing CRUD operations on simple objects is 
really good (overhead against plain JDBC is <10% for OJB 1.0.1) and in 
next version additional performance improvements will be done.
OJB was shipped with a simple performance test (call 'ant perf-test')



> Regards,
> Ludovic
> Armin Waibel wrote:
>> Hi Ludovic,
>> thanks for detailed list of patches and the description of usage.
>> Inheritance
>> -------------
>> I agree with you, to make the undocumented "extends-feature" (relict 
>> of an attempt to support inheritance many versions ago ;-)) by setting 
>> 'extends' attribute in class-descriptor work in some way, your patches 
>> are needed.
>> But I'm in doubt that current implementation is a good way to 
>> implement an official inheritance support, because we always have to 
>> (recursive) check for super-classes when using a class-desriptor. This 
>> will be possible in OJB kernel classes, but it have to be noted in 
>> top-level implementations and by the user too - think this is not 
>> practical.
>> A ClassDescriptor instance should contain all 
>> Field/ReferenceDescriptor of representing class. So the inherited 
>> fields should be copied from the super-class at startup of OJB or by 
>> the MetadataManager at runtime (in some way ;-)).
>> QueryReferenceBroker#retrieveReference
>> -----------------------------
>> <snip>
>>     if (id == null)
>>     {
>>          refObj = null;
>>     } //JMM : why not see if the object has already been loaded
>>     else if ( pb.serviceObjectCache().lookup(id) != null )
>>     {
>>        //LMA : Why refetch the objects ? they are already in cache!
>>        //refObj = pb.doGetObjectByIdentity(id);
>>        refObj = pb.serviceObjectCache().lookup(id);
>>     }
>> </snip>
>> If the user set 'refresh="true"' in class-descriptor OJB guaranteed 
>> that all specified fields in class-descriptor be refreshed from the DB 
>> on each lookup of the object. Think thats the reason why 
>> 'pb.doGetObjectByIdentity' was used.
>> regards,
>> Armin
> ---------------------------------------------------------------------
> 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

View raw message