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 Sun, 22 Jun 2003 21:55:27 GMT
Hi Thomas,

> That also works fine, as ConcreteZ and ConcreteZZ are stored in
> different tables.

ok, that's what I mean (in this case a single table doesn't
work). I will update the test case
using different tables for the concrete classes.

regards,
Armin

----- Original Message -----
From: "Thomas Mahler" <thma32@web.de>
To: "OJB Developers List" <ojb-dev@db.apache.org>
Sent: Sunday, June 22, 2003 10:39 PM
Subject: Re: [VOTE] Re: Issue #OJB187 - interfaces and abstract class as
element-clas s-ref


> Hi Armin,
>
> Armin Waibel wrote:
> > 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?
>
> It should be possible!
> And as mentioned in my original post the whole testcases passes, if we
> define the interface extent as:
> <class-descriptor class="AbstractExtentClassTest$AbstractIF_X">
>    <extent-class class-ref="AbstractExtentClassTest$ConcreteZ" />
>    <extent-class class-ref="AbstractExtentClassTest$ConcreteZZ" />
> </class-descriptor>
>
>
> > 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()?
>
> That also works fine, as ConcreteZ and ConcreteZZ are stored in
> different tables.
>
> So the issue real boils down to:
> Should the feature "inheritance for ClassDescriptors" be part of 1.0
or
> not.
> As I stated before:
> I think having inheritance in the repository is *nice to have*, but
*not
> mandatory* for 1.0. My wokaround shows that it is already possible to
> get the testcase pass without code changes only by tweaking the
mapping
> a bit. So this is no showstoper at all.
>
> But if we say it is a 1.0 feature, we have additional delay!
> That's why I'd like to see it out of 1,0 scope.
>
> cheers,
> Thomas
>
> >
> > 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
> >>
> >>
> >>
> >
> >
> >
> >
>
> ---------------------------------------------------------------------
> > 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