db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From oliver.m...@ppi.de
Subject Issue #OJB187 - interfaces and abstract class as element-class-re f
Date Mon, 16 Jun 2003 12:08:39 GMT
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


Mime
View raw message