You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-user@db.apache.org by Marcus Young <ma...@redcentre.com> on 2004/07/04 01:15:52 UTC
Difficultity with abstract mapping
Hi,
I have just been working an issue related to mapping abstract classes.
I've read quite a lot about it but I'm still unclear. The structure I
have is as follows:
Abstract Class A which can hold a collection of 'A' objects.
Classes B and C which extend A
Each class is mapped to a separate table.
I am hoping to be able to retreive records in such a way as to 'build'
an 'A' class object including the objects collection which may include
objects of class B and C. So far I have been working with 'super' and
'extents' - but to be honest I'm not really sure how to get it working.
Most commonly I'm getting exceptions of "InstantiationException". -
this appears to be related to the abstract 'A' class? I can resolve
this particular exception by using a concrete class, however I
particularly wanted to use an abstract class. Any assistance would be
greatly appreciated.
I end up with something like this:
public abstract class A extends TransferObject
{
protected Long _id;
}
public class B extends A
{
private String _name;
private String _description;
*}
*public class C extends A
{
private String _name;
private String _description;
*}
* <class-descriptor
class="com.eclipsej.permission.A" table="A">
<field-descriptor
name="_id"
column="ID"
jdbc-type="BIGINT"
primarykey="true"
autoincrement="true"
/>
<!-- extent-class class-ref="com.eclipsej.user.B" / -->
</class-descriptor>
<!-- Defnitions for com.eclipsej.user.B -->
<class-descriptor class="com.eclipsej.user.B" table="roles">
<field-descriptor name="_id" column="ID" jdbc-type="BIGINT"
primarykey="true" autoincrement="true"/>
<field-descriptor name="_name" column="NAME" jdbc-type="VARCHAR"/>
<field-descriptor name="_description" column="DESCRIPTION"
jdbc-type="VARCHAR"/>
<reference-descriptor name="super"
class-ref="com.eclipsej.permission.A"
auto-retreive="true" auto-update="true" auto-delete="true">
<foreignkey field-ref="_id"/>
</reference-descriptor>
</class-descriptor>*
*
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Difficultity with abstract mapping
Posted by ma...@redcentre.com.
Thanks Armin,
I'm starting to get a much better understanding re
persisting abstract classes. I have been able to
build some abstract and non-abstract test classes
that function correctly.
marcus
> marcus@redcentre.com wrote:
>
> > Hi Armin,
> >
> > yes - I tried defining an extent and the appropriate
> > class-descriptor's - I also experimented with
> > "super". I assume that I am correct in assuming
> > that it "is" possible to build such a structure with
> > an abstract class?
> >
>
> yep, I wrote a test case (using "extent" and different tables, as
> described on my last post) on my local machine and it work without
> problems (store/delete graph of objects).
> Pay attention not to mix different mapping strategy, e.g. use "extent"
> and "super" for the same classes, this could cause side-effects.
>
> It should also be possible store the whole graph in one table using
> "ojbConcreteClass" feature.
>
> regards,
> Armin
>
> > regards,
> >
> > Marcus
> >
> >
> >
> >
> >>Hi Marcus,
> >>
> >>did you try to declare class-descriptor's for B and C (including all
> >>fields and references) and define an extent for class A:
> >>
> >><class-descriptor class="A">
> >> <extent-class class-ref="B" />
> >> <extent-class class-ref="C" />
> >></class-descriptor>
> >>
> >>regards,
> >>Armin
> >>
> >>Marcus Young wrote:
> >>
> >>
> >>>Hi,
> >>>
> >>>I have just been working an issue related to mapping abstract classes.
> >>>I've read quite a lot about it but I'm still unclear. The structure I
> >>>have is as follows:
> >>>
> >>>Abstract Class A which can hold a collection of 'A' objects.
> >>>Classes B and C which extend A
> >>>Each class is mapped to a separate table.
> >>>
> >>>I am hoping to be able to retreive records in such a way as to 'build'
> >>>an 'A' class object including the objects collection which may include
> >>>objects of class B and C. So far I have been working with 'super' and
> >>>'extents' - but to be honest I'm not really sure how to get it working.
> >>>Most commonly I'm getting exceptions of "InstantiationException". -
> >>>this appears to be related to the abstract 'A' class? I can resolve
> >>>this particular exception by using a concrete class, however I
> >>>particularly wanted to use an abstract class. Any assistance would be
> >>>greatly appreciated.
> >>>
> >>>I end up with something like this:
> >>>
> >>>public abstract class A extends TransferObject
> >>>{ protected Long _id;
> >>>}
> >>>
> >>>public class B extends A
> >>>{
> >>> private String _name;
> >>> private String _description;
> >>>*}
> >>>
> >>>*public class C extends A
> >>>{
> >>> private String _name;
> >>> private String _description;
> >>>*}
> >>>
> >>>* <class-descriptor
> >>> class="com.eclipsej.permission.A" table="A">
> >>> <field-descriptor
> >>> name="_id"
> >>> column="ID"
> >>> jdbc-type="BIGINT"
> >>> primarykey="true"
> >>> autoincrement="true"
> >>> />
> >>> <!-- extent-class class-ref="com.eclipsej.user.B" / -->
> >>> </class-descriptor>
> >>><!-- Defnitions for com.eclipsej.user.B -->
> >>> <class-descriptor class="com.eclipsej.user.B" table="roles">
> >>> <field-descriptor name="_id" column="ID" jdbc-type="BIGINT"
> >>>primarykey="true" autoincrement="true"/>
> >>> <field-descriptor name="_name" column="NAME" jdbc-type="VARCHAR"/>
> >>> <field-descriptor name="_description" column="DESCRIPTION"
> >>>jdbc-type="VARCHAR"/> <reference-descriptor name="super"
> >>>class-ref="com.eclipsej.permission.A"
> >>> auto-retreive="true" auto-update="true" auto-delete="true">
> >>> <foreignkey field-ref="_id"/>
> >>> </reference-descriptor> </class-descriptor>*
> >>>*
> >>>
> >>>
> >>>---------------------------------------------------------------------
> >>>To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> >>>For additional commands, e-mail: ojb-user-help@db.apache.org
> >>>
> >>>
> >>>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> >>For additional commands, e-mail: ojb-user-help@db.apache.org
> >>
> >>
> >
> >
> > Unix Systems Administrator
> >
> > +61 3 9873 0155
> > +61 3 9720 7467 (fax)
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> > For additional commands, e-mail: ojb-user-help@db.apache.org
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Difficultity with abstract mapping
Posted by Armin Waibel <ar...@apache.org>.
marcus@redcentre.com wrote:
> Hi Armin,
>
> yes - I tried defining an extent and the appropriate
> class-descriptor's - I also experimented with
> "super". I assume that I am correct in assuming
> that it "is" possible to build such a structure with
> an abstract class?
>
yep, I wrote a test case (using "extent" and different tables, as
described on my last post) on my local machine and it work without
problems (store/delete graph of objects).
Pay attention not to mix different mapping strategy, e.g. use "extent"
and "super" for the same classes, this could cause side-effects.
It should also be possible store the whole graph in one table using
"ojbConcreteClass" feature.
regards,
Armin
> regards,
>
> Marcus
>
>
>
>
>>Hi Marcus,
>>
>>did you try to declare class-descriptor's for B and C (including all
>>fields and references) and define an extent for class A:
>>
>><class-descriptor class="A">
>> <extent-class class-ref="B" />
>> <extent-class class-ref="C" />
>></class-descriptor>
>>
>>regards,
>>Armin
>>
>>Marcus Young wrote:
>>
>>
>>>Hi,
>>>
>>>I have just been working an issue related to mapping abstract classes.
>>>I've read quite a lot about it but I'm still unclear. The structure I
>>>have is as follows:
>>>
>>>Abstract Class A which can hold a collection of 'A' objects.
>>>Classes B and C which extend A
>>>Each class is mapped to a separate table.
>>>
>>>I am hoping to be able to retreive records in such a way as to 'build'
>>>an 'A' class object including the objects collection which may include
>>>objects of class B and C. So far I have been working with 'super' and
>>>'extents' - but to be honest I'm not really sure how to get it working.
>>>Most commonly I'm getting exceptions of "InstantiationException". -
>>>this appears to be related to the abstract 'A' class? I can resolve
>>>this particular exception by using a concrete class, however I
>>>particularly wanted to use an abstract class. Any assistance would be
>>>greatly appreciated.
>>>
>>>I end up with something like this:
>>>
>>>public abstract class A extends TransferObject
>>>{ protected Long _id;
>>>}
>>>
>>>public class B extends A
>>>{
>>> private String _name;
>>> private String _description;
>>>*}
>>>
>>>*public class C extends A
>>>{
>>> private String _name;
>>> private String _description;
>>>*}
>>>
>>>* <class-descriptor
>>> class="com.eclipsej.permission.A" table="A">
>>> <field-descriptor
>>> name="_id"
>>> column="ID"
>>> jdbc-type="BIGINT"
>>> primarykey="true"
>>> autoincrement="true"
>>> />
>>> <!-- extent-class class-ref="com.eclipsej.user.B" / -->
>>> </class-descriptor>
>>><!-- Defnitions for com.eclipsej.user.B -->
>>> <class-descriptor class="com.eclipsej.user.B" table="roles">
>>> <field-descriptor name="_id" column="ID" jdbc-type="BIGINT"
>>>primarykey="true" autoincrement="true"/>
>>> <field-descriptor name="_name" column="NAME" jdbc-type="VARCHAR"/>
>>> <field-descriptor name="_description" column="DESCRIPTION"
>>>jdbc-type="VARCHAR"/> <reference-descriptor name="super"
>>>class-ref="com.eclipsej.permission.A"
>>> auto-retreive="true" auto-update="true" auto-delete="true">
>>> <foreignkey field-ref="_id"/>
>>> </reference-descriptor> </class-descriptor>*
>>>*
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>>For additional commands, e-mail: ojb-user-help@db.apache.org
>>>
>>>
>>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>For additional commands, e-mail: ojb-user-help@db.apache.org
>>
>>
>
>
> Unix Systems Administrator
>
> +61 3 9873 0155
> +61 3 9720 7467 (fax)
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Difficultity with abstract mapping
Posted by ma...@redcentre.com.
Hi Armin,
yes - I tried defining an extent and the appropriate
class-descriptor's - I also experimented with
"super". I assume that I am correct in assuming
that it "is" possible to build such a structure with
an abstract class?
regards,
Marcus
> Hi Marcus,
>
> did you try to declare class-descriptor's for B and C (including all
> fields and references) and define an extent for class A:
>
> <class-descriptor class="A">
> <extent-class class-ref="B" />
> <extent-class class-ref="C" />
> </class-descriptor>
>
> regards,
> Armin
>
> Marcus Young wrote:
>
> > Hi,
> >
> > I have just been working an issue related to mapping abstract classes.
> > I've read quite a lot about it but I'm still unclear. The structure I
> > have is as follows:
> >
> > Abstract Class A which can hold a collection of 'A' objects.
> > Classes B and C which extend A
> > Each class is mapped to a separate table.
> >
> > I am hoping to be able to retreive records in such a way as to 'build'
> > an 'A' class object including the objects collection which may include
> > objects of class B and C. So far I have been working with 'super' and
> > 'extents' - but to be honest I'm not really sure how to get it working.
> > Most commonly I'm getting exceptions of "InstantiationException". -
> > this appears to be related to the abstract 'A' class? I can resolve
> > this particular exception by using a concrete class, however I
> > particularly wanted to use an abstract class. Any assistance would be
> > greatly appreciated.
> >
> > I end up with something like this:
> >
> > public abstract class A extends TransferObject
> > { protected Long _id;
> > }
> >
> > public class B extends A
> > {
> > private String _name;
> > private String _description;
> > *}
> >
> > *public class C extends A
> > {
> > private String _name;
> > private String _description;
> > *}
> >
> > * <class-descriptor
> > class="com.eclipsej.permission.A" table="A">
> > <field-descriptor
> > name="_id"
> > column="ID"
> > jdbc-type="BIGINT"
> > primarykey="true"
> > autoincrement="true"
> > />
> > <!-- extent-class class-ref="com.eclipsej.user.B" / -->
> > </class-descriptor>
> > <!-- Defnitions for com.eclipsej.user.B -->
> > <class-descriptor class="com.eclipsej.user.B" table="roles">
> > <field-descriptor name="_id" column="ID" jdbc-type="BIGINT"
> > primarykey="true" autoincrement="true"/>
> > <field-descriptor name="_name" column="NAME" jdbc-type="VARCHAR"/>
> > <field-descriptor name="_description" column="DESCRIPTION"
> > jdbc-type="VARCHAR"/> <reference-descriptor name="super"
> > class-ref="com.eclipsej.permission.A"
> > auto-retreive="true" auto-update="true" auto-delete="true">
> > <foreignkey field-ref="_id"/>
> > </reference-descriptor> </class-descriptor>*
> > *
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> > For additional commands, e-mail: ojb-user-help@db.apache.org
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
Unix Systems Administrator
+61 3 9873 0155
+61 3 9720 7467 (fax)
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Difficultity with abstract mapping
Posted by ma...@redcentre.com.
Martin,
on thinking about it - a single table may be the
best approach. One of my objectives is to be able
to build a collection of different objects (all from
the same base class) - a sort of recursive
collection. It seems that "ojbConcreteClass" would
provide support for this - I'm not really sure how
else it could be done.
Marcus
> good and bad table design is disputable, but in fact; if you use Oracle
> Designer for example, they use exactly this approach for all
> generalization-relationships by default.
>
> -Martin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
Unix Systems Administrator
+61 3 9873 0155
+61 3 9720 7467 (fax)
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Difficultity with abstract mapping
Posted by David Zejda <dv...@atlas.cz>.
The main problem with tables denormalised to contain more real world
entities is possibility to fill unrelated fields (e.g. both from Group
and Role). But if you let the persistency completely on mapping tool
(OJB), you don't have to worry about it - OJB will not mangle them..
The main remaining con of mapping to one table (in most situations) is
the size of the database - it will be a bit bigger.
But, across as there will be no need to joins, the scenario will be
faster than separate tables..
But I'm also not a db expert, so I may be wrong..
David
marcus@redcentre.com wrote:
> David,
>
> thanks for your comments. The main problem that I
> see with this approach is that each of the classes
> inheriting from the abstract class have very
> different attributes - so there will be a lot of
> empty fields in the table - I am not an expert,
> however I would assume that this is not good table
> design? For example, the actual classes I am trying
> to build are "PermissionHolder" (abstract) and User,
> Role and Group (concrete). User has many more
> attributes than the Group and Role. Do you see this
> as an issue?
>
> It is interesting that if I use a concrete class as
> the parent (rather than abstract) I seem to be able
> to store and retreive - a least in simple test
> cases.
>
> Marcus
>
>
>
>
>>Marcus Young wrote:
>>
>>
>>>Each class is mapped to a separate table.
>>
>>I persuaded, that it's much easier to map the whole hierarchy to one
>>table and provide ojbConcreteClass..
>>
>>David
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Difficultity with abstract mapping
Posted by Martin Marinschek <ge...@hotmail.com>.
good and bad table design is disputable, but in fact; if you use Oracle
Designer for example, they use exactly this approach for all
generalization-relationships by default.
-Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Difficultity with abstract mapping
Posted by ma...@redcentre.com.
David,
thanks for your comments. The main problem that I
see with this approach is that each of the classes
inheriting from the abstract class have very
different attributes - so there will be a lot of
empty fields in the table - I am not an expert,
however I would assume that this is not good table
design? For example, the actual classes I am trying
to build are "PermissionHolder" (abstract) and User,
Role and Group (concrete). User has many more
attributes than the Group and Role. Do you see this
as an issue?
It is interesting that if I use a concrete class as
the parent (rather than abstract) I seem to be able
to store and retreive - a least in simple test
cases.
Marcus
> Marcus Young wrote:
>
> > Each class is mapped to a separate table.
>
> I persuaded, that it's much easier to map the whole hierarchy to one
> table and provide ojbConcreteClass..
>
> David
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Difficultity with abstract mapping
Posted by Armin Waibel <ar...@apache.org>.
Hi Marcus,
did you try to declare class-descriptor's for B and C (including all
fields and references) and define an extent for class A:
<class-descriptor class="A">
<extent-class class-ref="B" />
<extent-class class-ref="C" />
</class-descriptor>
regards,
Armin
Marcus Young wrote:
> Hi,
>
> I have just been working an issue related to mapping abstract classes.
> I've read quite a lot about it but I'm still unclear. The structure I
> have is as follows:
>
> Abstract Class A which can hold a collection of 'A' objects.
> Classes B and C which extend A
> Each class is mapped to a separate table.
>
> I am hoping to be able to retreive records in such a way as to 'build'
> an 'A' class object including the objects collection which may include
> objects of class B and C. So far I have been working with 'super' and
> 'extents' - but to be honest I'm not really sure how to get it working.
> Most commonly I'm getting exceptions of "InstantiationException". -
> this appears to be related to the abstract 'A' class? I can resolve
> this particular exception by using a concrete class, however I
> particularly wanted to use an abstract class. Any assistance would be
> greatly appreciated.
>
> I end up with something like this:
>
> public abstract class A extends TransferObject
> { protected Long _id;
> }
>
> public class B extends A
> {
> private String _name;
> private String _description;
> *}
>
> *public class C extends A
> {
> private String _name;
> private String _description;
> *}
>
> * <class-descriptor
> class="com.eclipsej.permission.A" table="A">
> <field-descriptor
> name="_id"
> column="ID"
> jdbc-type="BIGINT"
> primarykey="true"
> autoincrement="true"
> />
> <!-- extent-class class-ref="com.eclipsej.user.B" / -->
> </class-descriptor>
> <!-- Defnitions for com.eclipsej.user.B -->
> <class-descriptor class="com.eclipsej.user.B" table="roles">
> <field-descriptor name="_id" column="ID" jdbc-type="BIGINT"
> primarykey="true" autoincrement="true"/>
> <field-descriptor name="_name" column="NAME" jdbc-type="VARCHAR"/>
> <field-descriptor name="_description" column="DESCRIPTION"
> jdbc-type="VARCHAR"/> <reference-descriptor name="super"
> class-ref="com.eclipsej.permission.A"
> auto-retreive="true" auto-update="true" auto-delete="true">
> <foreignkey field-ref="_id"/>
> </reference-descriptor> </class-descriptor>*
> *
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Difficultity with abstract mapping
Posted by David Zejda <dv...@atlas.cz>.
Marcus Young wrote:
> Each class is mapped to a separate table.
I persuaded, that it's much easier to map the whole hierarchy to one
table and provide ojbConcreteClass..
David
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org