db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Mahler <thm...@web.de>
Subject [VOTE] Re: Issue #OJB187 - interfaces and abstract class as element-clas s-ref
Date Fri, 20 Jun 2003 13:09:51 GMT
Hi all,

Armin checked in the testcase for this issue.
The testcases produces 2 errors.
These errors have to go away before the next release!

So we have to decide how to approach the problem.
I debugged a little and found that the only thing that make OJB unhappy 
is the following extent definition:

<class-descriptor class="AbstractExtentClassTest$AbstractIF_X">
   <extent-class class-ref="AbstractExtentClassTest$AbstractIF_Y" />
   <extent-class class-ref="AbstractExtentClassTest$AbstractClassX" />
</class-descriptor>

The Problem is that the OJB extent mechanism does only work with
extent-class references to concrete classes. It was never meant to 
support inheritance.

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>

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?

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)

what do you think?

cheers,
Thomas

Thomas Mahler wrote:
> hi again olli,
> 
> <snip>
> 
>>
>>> I'd prefer to have the field-descriptor only in *all* classes 
>>> (abstract or concrete) that actually provide the java attribute 
>>> "containerId".
>>
>>
>>
>> By 'attribute' you mean a Java field, don't you?  
> 
> 
> corect!
> 
>> What about
>> a class or interface that provides for abstract bean accessor/mutator?
>>
> 
> you are right. I was only thinking about using the 
> PersistentFieldDefaultImpl. having a mapping in an interface or abstract 
> class descriptor will be ok if PersistenFieldPropertyImpl is used.
> 
>>
>>>> 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 
>>
>>
>>
>> [..]
>>
>>
>>> So I'm not really enthusiatic about this feature...
>>
>>
>>
>> Neither am I.  For our project, it does not really matter anyway,
>> because we use code generation for the repository_user.xml
>>
> 
> Most larger projects use some kind of generation for the repository. so 
> it's no real pain to have information duplicated in the generated file.
> 
>>
>>>> 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!
>>
>>
>>
>> It is easy to implement, but this change of behaviour will
>> force users to adapt their repository files, so it should
>> be stated clearly in the documentation.  
> 
> 
> We are pros in having up to date documentation ;-)
> 
>> What about software that generates the repository_user.xml, such as 
>> Axgen?
> 
> 
> they'll be happy to follow our changes (I hope so ;-))
> 
>> All in all, it would be nice to have a less tolerant parser
>> for the repository.xml.  As to my experience, inconsistencies in it 
>> lead to very surprising runtime errors right now.
>> But I know that this would mean a lot of maintenance effort.
> 
> 
> Verifying a repository ia an art in it self. Of course there are aspects 
> that could be checked mechanically, But there are also all kind of 
> "grey" areas, where an automated check won't be a big help.
> 
> 
>> I have not tried the VerifyMappingsTask yet.  Is it good?
> 
> It's a good start at least. But things get difficult very fast.
> For example the Verifier checks Java field types against the definitions 
> in the repository *and* also against the actual JDBC types of the mapped 
> columns in the DB.
> So far so good. But it does not check against the FieldConversions that 
> come also into play. As FieldConversions are not strictly typed it's not 
> possible to statitically compute which types the Conversion takes as 
> input and output.
> 
> So the Verifier will complain if an INTEGER column is mapped on a 
> Boolean field, even if a Boolean2IntFieldConversion is defined!
> 
> ( Sometimes I'd appreciate to work with my old SML system again. Doing 
> such computation would be *very* simple with SML!)
> 
> cheers,
> Thomas
> 
>> It test only some rudimentary thin
> 
> 
>> Olli
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>
>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
> 
> 


Mime
View raw message