db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Mahler <thm...@web.de>
Subject Re: Issue #OJB187 - interfaces and abstract class as element-clas s-ref
Date Tue, 17 Jun 2003 17:06:43 GMT
hi again olli,

>>I'd prefer to have the field-descriptor only in *all* classes 
>>or concrete) that actually provide the java attribute "containerId".
> By 'attribute' you mean a Java field, don't you?  


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


> 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

View raw message