RE: [VOTE] Re: Issue #OJB187 - interfaces and abstract class as e lement-clas s-ref

[ol...@ppi.de]

Hello,

sorry for my late reaction, I had taken one day off on Friday. :-(

> -----Original Message-----
> From: Thomas Mahler [mailto:thma32@web.de]

> The whole testcase can be fixed by simply changing the extent 
> definition to:
> 
> <class-descriptor class="AbstractExtentClassTest$AbstractIF_X">
>    <extent-class class-ref="AbstractExtentClassTest$ConcreteZ" />
>    <extent-class class-ref="AbstractExtentClassTest$ConcreteZZ" />
> </class-descriptor>

Is is generally necessary/recommended to 'flatten' the inheritance
hierarchy in the repository.xml?  I mean, should every class-descriptor
for an interface (or abstract class) mention excactly the 
concrete classes ?
(Or those that are mapped to a table - these could be different ones)  
This does not seem to be intended in other parts of the code 
I came across.

This would mean some redundancy in the reprository.xml, because there
should be another class-descriptor for 
AbstractExtentClassTest$AbstractIF_Y and 
AbstractExtentClassTest$AbstractClassX mentioning 
AbstractExtentClassTest$ConcreteZ and 
AbstractExtentClassTest$ConcreteZZ.

BTW, there is another way to cure the testcase (untested):

Insert a field-descriptor for the containerId into the 
class-descriptor of AbstractIF_Y, i.e.:

<class-descriptor
   class="org.apache.ojb.broker.AbstractExtentClassTest$AbstractIF_Y">
  <extent-class
class-ref="org.apache.ojb.broker.AbstractExtentClassTest$ConcreteZ" />
  <field-descriptor
    name="containerId"
    column="CONTAINER_ID"
    jdbc-type="INTEGER"/>
</class-descriptor>

> So how to proceed?
> shall we [your votes please!]
> a) cure the testcase, or
> b) shall we work on the feature request and implement a inheritance 
> mechanism for class-descriptors?

My vote is (a) & explain the behaviour in the documentation and in
the test case comments.

> I have not seen Olivers suggest patch. So I don't know if it is a 
> generic solution and if there could be any side effects.
> 
> But to reduce risks for the 1.0 release I propose to proceed with b)

I do not see any risk in my patch, but I dislike it because it is
extra code that implements another undesirable behaviour.

Olli