Re: Issue #OJB187 - interfaces and abstract class as element-class-re f

[Thomas Mahler <th...@web.de>]

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

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

cheers,
thomas

> Olli
> 

Re: Issue #OJB187 - interfaces and abstract class as element-class-re f

[Jakob Braeuchi <jb...@gmx.ch>]

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