You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-dev@db.apache.org by ol...@ppi.de on 2003/06/16 14:08:39 UTC
Issue #OJB187 - interfaces and abstract class as element-class-re
f
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 ...)
(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)
(4) In every concrete class that implements AbstractIF_X?
(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.
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).
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.
Olli
--
Oliver Matz
ppi Media GmbH
Deliusstraße 10
D-24114 Kiel
phone +49 (0) 43 1-53 53-422
fax +49 (0) 43 1-53 53-2 22
email mailto:oliver.matz@ppi.de
web www.ppi.de
Re: Issue #OJB187 - interfaces and abstract class as element-class-re
f
Posted by 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
>
>
Re: Issue #OJB187 - interfaces and abstract class as element-class-re
f
Posted by 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
>