db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakob Braeuchi <jbraeu...@gmx.ch>
Subject Re: Issue #OJB187 - interfaces and abstract class as element-class-re f
Date Mon, 16 Jun 2003 20:39:29 GMT
hi thomas, oliver,

Thomas Mahler wrote:

> Hi Oliver,
>
> oliver.matz@ppi.de wrote:
>
>> Hello,
>>
>> there is a bug in the current OJB implementation in the
>> handling of an element-class-ref to an abstract class or an 
>> interface.  A test that reveals this bug is in current CVS head, see 
>> AbstractExtentClassTest.
>>
>> Armin and I had a discussion on what in desired behaviour
>> is.  We might continue this discussion here (see also Jakob's
>> mail.)
>>
>> Let me sketch the problem.
>>
>> There is a class XContainer with a collection of AbstractIF_X 
>> references, where AbstractIF_X is an interface.
>>
>>
>> <collection-descriptor
>>    name="myXReferences"
>>  
>> element-class-ref="org.apache.ojb.broker.AbstractExtentClassTest$AbstractIF_
>> X"
>>    auto-retrieve="true"
>>    auto-update="true"
>>    auto-delete="false">
>>        <inverse-foreignkey field-ref="containerId"/>
>> </collection-descriptor>
>>
>> In the failing test case, the field (or bean property) containerId, 
>> which serves as an inverse-foreignkey field, is located in the  
>> concrete class ConcreteZ that implements X
>> AbstractIF_X.  The test fails because there is another interface
>> in between ConcreteZ and AbstractIF_X.
>>
>> The question is, in which class-descriptor should the 
>> field-descriptor of containerId be declared in order to
>> make this work?
>>
>> (1) In the class-descriptor of AbstractIF_X     (remember that this 
>> is an interface ...)
>
>
> The interface is not mapped directly to a table. so specifying 
> field-descriptors here is a bit "smelly".
>
> But specifying "containerId" as inverse-foreignkey is smelly too.
> So there is no additional harm with (1)
>
>>
>> (2) In each concrete class that implements AbstractIF_X?
>>
>> (3) in the first class in the extent of AbstractIF_X
>>     (that is the current implementation)
>
>
> I agree this is no real solution !
>
>>
>> (4) In every concrete class that implements AbstractIF_X?
>
>
> same a (2) or did you mean "abstract class"?
>
>> (5) In every class that implements AbstractIF_X?
>>
>> (6) In AbstractIF_X and every class/interface that     
>> implements/extends AbstractIF_X?
>>
>> I think we agree that (3) is not acceptable, in particular because
>> the first 'class' in that extent might be an interface itsself.
>>
>> Personally, I do not have any problems with field-descriptors
>> in interfaces, so (1) and (6) are both fine with me.
>>
>> I even feel uncomfortable with the arbitrariness of taking the
>> field-descriptor of some class different from AbstractIF_X.
>>
>
> I'd prefer to have the field-descriptor only in *all* classes 
> (abstract or concrete) that actually provide the java attribute 
> "containerId".
>
>
>> If we allow inheritance of field-descriptors, this would
>> probably make a lot of things smoother, and in that case,
>> the answer would certainly be (1).
>
>
> ineheritance of fielddescriptors has been requested several times. We 
> had no real discussion about this issue so far.
> I see that the OJB repository does not work as Java wrt. to 
> inheritance, which makes it tricky to handle sometimes. 

how does jdo handle this problem ?

>
> The current solution is optimized for speed as all information is 
> explicit.
> If we would use inheritance, field-descriptors must be looked up 
> across complex inheritance trees.
> This could have serious impacts on performance!
> So I'm not really enthusiatic about this feature...

fielddescriptors are cached after the first call, so i think performance 
shoud not degrade too much. 
when we provide inheritence for fielddescriptors, then what about 
relationship-descriptors ?

>
>>
>> However, without inheritance of field-descriptors, I propose
>> the following:
>>
>> (+) The field-descriptor present in AbstractIF_X is
>>     the one taken for the considered collection field 'myXReferences'.
>>         Besides, the field-descriptor must be present in other
>>     classes as required by OJB's persistence-mechanism, i.e.,
>>     in every concrete class that wishes to store that field.
>
>
> sounds like a fair compromise! 

i agree.

jakob

>
>
> cheers,
> thomas
>
>> Olli
>>
>
>
> ---------------------------------------------------------------------
> 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