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: [OJB] Issue #OJB292 modified
Date Thu, 23 Sep 2004 08:04:17 GMT
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. 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, 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. 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.

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

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").


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

View raw message