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 Jakob Braeuchi <jb...@gmx.ch> on 2004/08/07 14:24:24 UTC
Proposal to get rid of ojbConcreteClass
hi all,
i think we need a more flexible approach when mapping multiple classes to one
single table. today we have the field-descriptor 'ojbConcreteClass', a working
solution i have to admit.
the biggest problem is imo that we always store the name of the class in the
database. this makes refactoring of the package structure unnecessarily
difficult. another, but minor issue, is that ojbConcreteClass is an ordinary
field-descriptor.
i propose to add some kind of concrete-selector to the class-descriptor. this
selector points to an ordinary field-descriptor. additionaly the selector may
have a value that is stored instead of the real class name. if no selector-value
is defined we could still use the class name as default:
<class-descriptor
class="org.apache.ojb.broker.ObjectRepository$A"
table="AB_TABLE"
selector-field-ref="my_conrete_class"
selector-field-value="class_a"
>
<field-descriptor
name="id"
column="ID"
jdbc-type="INTEGER"
primarykey="true"
autoincrement="true"
/>
<field-descriptor
name="my_conrete_class"
column="CLASS_NAME"
jdbc-type="VARCHAR"
/>
...
</class-descriptor>
as an alternative the selector could also be defined using a special element:
<class-descriptor
class="org.apache.ojb.broker.ObjectRepository$A"
table="AB_TABLE"
>
<selector-descriptor
field-ref="my_conrete_class"
value="class_a"
/>
<field-descriptor
name="id"
column="ID"
jdbc-type="INTEGER"
primarykey="true"
autoincrement="true"
/>
<field-descriptor
name="my_conrete_class"
column="CLASS_NAME"
jdbc-type="VARCHAR"
/>
...
</class-descriptor>
there's another proposal by andrew clute to include a class-selector in the
reference-descriptor:
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=ojb-dev@db.apache.org&msgNo=7861
actually this does not address the same problem, but we should make sure that
the naming is consistent.
what do you think ?
jakob
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: Proposal to get rid of ojbConcreteClass
Posted by Thomas Dudziak <to...@first.fhg.de>.
Jakob Braeuchi wrote:
> the jdo approach may be even better because it does not reference an
> ordinary field. so we could also move the relevant jdbc-information into
> the selector:
>
> <class-descriptor
> class="org.apache.ojb.broker.ObjectRepository$A"
> table="AB_TABLE"
> >
> <selector-descriptor
> column="class_mame"
> jdbc-type="STRING"
> value="class_a"
> />
> <field-descriptor
> name="id"
> column="ID"
> jdbc-type="INTEGER"
> primarykey="true"
> autoincrement="true"
> />
> ...
> </class-descriptor>
JDO has a special descriptor that defines the inheritance strategy:
<inheritance strategy="superclass-table">
<discriminator strategy="class-name" column="JAVA_CLS"/>
</inheritance>
The strategy is either new-table (one table per class), superclass-table
(mapped to the same table as the - in respect to persistence - direct
superclass), and no-table (fields of this subclass are in a separate
table, i.e. our multiple-joined tables strategy). Depending on the
strategy, the discriminator specifies the connection point(s).
Perhaps it would be useful to adapt this pattern (and the some of the
names), e.g. deprecate the super-reference and put it in such a special
descriptor ?
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: Proposal to get rid of ojbConcreteClass
Posted by Jakob Braeuchi <jb...@gmx.ch>.
hi thomas,
the jdo approach may be even better because it does not reference an ordinary
field. so we could also move the relevant jdbc-information into the selector:
<class-descriptor
class="org.apache.ojb.broker.ObjectRepository$A"
table="AB_TABLE"
>
<selector-descriptor
column="class_mame"
jdbc-type="STRING"
value="class_a"
/>
<field-descriptor
name="id"
column="ID"
jdbc-type="INTEGER"
primarykey="true"
autoincrement="true"
/>
...
</class-descriptor>
jakob
Thomas Dudziak schrieb:
> Brian McCallister wrote:
>
>> +1 for selector element. It feels similar to how we do extents now.
>>
>> Something to consider -- may be worth looking at how JDO 2.0 mapping
>> handles it.
>
>
> It uses the same approach as we do: a discriminator column specifies the
> class that the row belongs to (see 15.7 Inheritance in JDO2 spec).
>
> Tom
>
> ---------------------------------------------------------------------
> 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: Proposal to get rid of ojbConcreteClass
Posted by Thomas Dudziak <to...@first.fhg.de>.
Brian McCallister wrote:
> +1 for selector element. It feels similar to how we do extents now.
>
> Something to consider -- may be worth looking at how JDO 2.0 mapping
> handles it.
It uses the same approach as we do: a discriminator column specifies the
class that the row belongs to (see 15.7 Inheritance in JDO2 spec).
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: Proposal to get rid of ojbConcreteClass
Posted by Brian McCallister <mc...@forthillcompany.com>.
+1 for selector element. It feels similar to how we do extents now.
Something to consider -- may be worth looking at how JDO 2.0 mapping
handles it.
-Brian
On Aug 7, 2004, at 8:24 AM, Jakob Braeuchi wrote:
> hi all,
>
> i think we need a more flexible approach when mapping multiple classes
> to one single table. today we have the field-descriptor
> 'ojbConcreteClass', a working solution i have to admit.
> the biggest problem is imo that we always store the name of the class
> in the database. this makes refactoring of the package structure
> unnecessarily difficult. another, but minor issue, is that
> ojbConcreteClass is an ordinary field-descriptor.
>
> i propose to add some kind of concrete-selector to the
> class-descriptor. this selector points to an ordinary
> field-descriptor. additionaly the selector may have a value that is
> stored instead of the real class name. if no selector-value is defined
> we could still use the class name as default:
>
> <class-descriptor
> class="org.apache.ojb.broker.ObjectRepository$A"
> table="AB_TABLE"
> selector-field-ref="my_conrete_class"
> selector-field-value="class_a"
> >
> <field-descriptor
> name="id"
> column="ID"
> jdbc-type="INTEGER"
> primarykey="true"
> autoincrement="true"
> />
> <field-descriptor
> name="my_conrete_class"
> column="CLASS_NAME"
> jdbc-type="VARCHAR"
> />
> ...
> </class-descriptor>
>
> as an alternative the selector could also be defined using a special
> element:
>
> <class-descriptor
> class="org.apache.ojb.broker.ObjectRepository$A"
> table="AB_TABLE"
> >
> <selector-descriptor
> field-ref="my_conrete_class"
> value="class_a"
> />
>
> <field-descriptor
> name="id"
> column="ID"
> jdbc-type="INTEGER"
> primarykey="true"
> autoincrement="true"
> />
> <field-descriptor
> name="my_conrete_class"
> column="CLASS_NAME"
> jdbc-type="VARCHAR"
> />
> ...
> </class-descriptor>
>
> there's another proposal by andrew clute to include a class-selector
> in the reference-descriptor:
>
> http://nagoya.apache.org/eyebrowse/ReadMsg?listName=ojb-
> dev@db.apache.org&msgNo=7861
>
> actually this does not address the same problem, but we should make
> sure that the naming is consistent.
>
> what do you think ?
>
> jakob
>
>
> ---------------------------------------------------------------------
> 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