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 Mahler Thomas <th...@itellium.com> on 2003/06/23 11:28:28 UTC

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

Hi again,

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

That was my intention with the current design. I know it's not that elegant,
but easy to implement ;-) 

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

Yes, that's one of the drawbacks of this approach!

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

I'll give it a try. this would be less counter intuitive than my workaround.

> 
> > 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, could you please post me your patch, I did not review the code yet!

cheers,
Thomas

> 
> Olli
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
> 
>