db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakob Braeuchi <jbraeu...@gmx.ch>
Subject Re: [VOTE] Re: Issue #OJB187 - interfaces and abstract class as element-clas s-ref
Date Fri, 20 Jun 2003 18:28:27 GMT
hi,

+ 1 for b.)

but as we discussed in prevoius posts, it does not have to be 
inheritence... defining the fields in the interface would be sufficient.

jakob

Thomas Mahler wrote:

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