You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-dev@db.apache.org by Thomas Mahler <th...@web.de> on 2003/06/17 19:06:43 UTC
Re: Issue #OJB187 - interfaces and abstract class as element-clas
s-ref
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
>
>
Re: [VOTE] Re: Issue #OJB187 - interfaces and abstract class as element-clas s-ref
Posted by Armin Waibel <ar...@code-au-lait.de>.
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" <th...@web.de>
To: "OJB Developers List" <oj...@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" <jb...@gmx.ch>
> > To: "OJB Developers List" <oj...@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
>
>
Re: [VOTE] Re: Issue #OJB187 - interfaces and abstract class as element-clas
s-ref
Posted by Thomas Mahler <th...@web.de>.
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" <jb...@gmx.ch>
> To: "OJB Developers List" <oj...@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
>
>
Re: [VOTE] Re: Issue #OJB187 - interfaces and abstract class as element-clas s-ref
Posted by Armin Waibel <ar...@code-au-lait.de>.
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" <jb...@gmx.ch>
To: "OJB Developers List" <oj...@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
>
>
>
Re: [VOTE] Re: Issue #OJB187 - interfaces and abstract class as element-clas
s-ref
Posted by Jakob Braeuchi <jb...@gmx.ch>.
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
>
>
[VOTE] Re: Issue #OJB187 - interfaces and abstract class as element-clas
s-ref
Posted by Thomas Mahler <th...@web.de>.
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
>
>