db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Armin Waibel" <ar...@code-au-lait.de>
Subject Re: [VOTE] Re: Issue #OJB187 - interfaces and abstract class as element-clas s-ref
Date Sat, 21 Jun 2003 18:17:37 GMT
Hi all,

I'm not an expert on this issue (only checked in the
test case), thus I'm not qualified to vote.
But apart from the 'inheritance problem' I have a
questions:

In the test case the XContainer has
a CollectionDescriptor using a element-class-ref
pointing to an Interface (or abstract class - whatever).
Does this make sense without using ojbConcreteClass?

If I store (using XContainer.addX and then store XContainer)
two different concrete classes implementing
the Interface but also having additional non-pk fields
what will be the result of XContainer.getXReferences()?

regards,
Armin

----- Original Message -----
From: "Jakob Braeuchi" <jbraeuchi@gmx.ch>
To: "OJB Developers List" <ojb-dev@db.apache.org>
Sent: Friday, June 20, 2003 8:28 PM
Subject: Re: [VOTE] Re: Issue #OJB187 - interfaces and abstract class as
element-clas s-ref


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