db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Mahler <thm...@web.de>
Subject Re: Identity.realClass and Identity.topLevelClass
Date Fri, 29 Aug 2003 09:46:00 GMT
Hi Oliver,

oliver.matz@ppi.de wrote:
> Hello,
> 
> Armin and I have discussed a problem (in this list)
> that seems to have popped up at the Users' list, too.
> ("Potential Identity bug involving mulitple extents.")
> 
> I have had an idea how to improve the Identity class:
> It should have three (rather than two) fields to
> store the object's class:
> 
> 1. realClass - the object's concrete class, i.e.,
>                the result of obj.getClass() (as before)
> 2. lowestKnownClass - the lowest persistence-capable class
>                    or interface (in the inheritance hierarchy)
>                    that the identified object is known
>                    to be an instance of.
> 3. topLevelClass - the highest persistence-capable 
>                    class or interface (in the inheritance hierarchy)
>                    that the identified object is an instance of 
>                    (as before)
> Suppose you have three pc class C extends B extends A,
> and a reference of type B referencing an instance of class C.
> 
> When this reference is traversed, the Identity will have
> realClass=null, lowesetKnownClass=B, topLevelClass=A.
> Consequently, the tables for B and its subclasses (including C)
> will have to be searched in, but not the table for class A.
> 
> After the object has been instantiated, the realClass will be C.
> 
> I consider this a performance improvement.

I agree that in your example (class C extends B extends A) it will be a 
performance improvement.

But will it be a performance improvement for arbitrary other situations 
(say class E extends D extends C extends B extends A) ?
There could be some reference descriptors pointing to A, some others 
pointing to B and even others pointing to C and D.
How can the lowestKnownClass help in this case?

> 
> The issue with multiple inheritance remains unsolved, though.

I don't see a viable solution to this problem.
If Identities were based on the realClass attribute, there won't be this 
conflict multiple inheritance. BUT we won't be able to specify 
Identities for abstract baseclasses or interfaces then. So this is no an 
option.

If we want to be able to specify indenties that are unique across 
inheritance hierarchies (that is allow identies for abstract baseclasses 
and interfaces), we automatically collide with classes implementing 
multiple interfaces (only if those interfaces are defined as persistence 
capable in the repository).

> The documentation should state clearly that there
> should be a unique top-level pc class for
> every connected component in the inheritance hierarchy.

I definitely agree with you, as I see no way to solve this issue by 
changing OJB!

cheers,
Thomas

> What do you think?
> 
> Olli
> 
> ---------------------------------------------------------------------
> 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