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/20 15:09:51 UTC
[VOTE] Re: Issue #OJB187 - interfaces and abstract class as element-clas
s-ref
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
>
>
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
>
>