AW: [Objectbridge-developers] [Fwd: [objectbridge - Open Discussi on] New repository.xml/dtd proposal.]

[Mahler T. <tho...@it...>]

Hi all,

> -----Urspr=FCngliche Nachricht-----
> Von: Dirk Olmes [mailto:di...@xa...]
> Gesendet: Mittwoch, 29. August 2001 06:32
> An: 'objectbridge'
> Betreff: Re: [Objectbridge-developers] [Fwd: [objectbridge - Open
> Discussion] New repository.xml/dtd proposal.]
>=20
>=20
> Lasse Lindg=E5rd schrieb:
> >=20
> > Something about this strikes me as beeing wrong - or at least
> > questionable.
> >=20
> > To me a persistence framework must be easy to work with,=20
> transperent and
> > flexible in that order.
>=20
> To me a persistence framework must be flexible, transparent=20
> and easy to
> work with, in that order. So there are obviously different design
> expectations :-)
>=20

As you will agree OJB has always been concerned to be flexible, =
transparent
and easy to use. regardless which order you apply ;-)

> > It is good to have the flexibility that the mapping files=20
> allows. But I
> > am wondering if the usecase in 99% of the cases is that you=20
> just want
> > the database names to be the same as the ones in the fields.
>=20

OJB always allowed to have different names for Object attributes and =
tables
column names. It is definitely no option to have a single name for =
both.

I don't quite see why Ivan's proposal won't allow to keep separate =
names for
attributes and columns.

Just have a look at his sample xml file:

Table definition:
 <table id=3D"Artikel" jdbc-ref=3D"default" name=3D"Artikel">
    <column type=3D"INTEGER" name=3D"Artikel_Nr" primary-key=3D"yes"/>
    <column type=3D"VARCHAR" name=3D"Artikelname"/>
    <column type=3D"INTEGER" name=3D"Lieferanten_Nr"/>
    <column type=3D"INTEGER" name=3D"Kategorie_Nr"/>
    <column type=3D"VARCHAR" name=3D"Liefereinheit"/>
    <column type=3D"FLOAT"   name=3D"Einzelpreis"/>
    <column type=3D"INTEGER" name=3D"Lagerbestand"/>
    <column type=3D"INTEGER" name=3D"BestellteEinheiten"/>
    <column type=3D"INTEGER" name=3D"MindestBestand"/>
    <column type=3D"INTEGER" name=3D"Auslaufartikel"/>
  </table>

Class definition:
 <class table-ref=3D"Artikel"
         name=3D"test.ojb.broker.Article"
         =
conversion-strategy=3D"test.ojb.broker.ArticleConversionStrategy"
         proxy=3D"test.ojb.broker.ArticleProxy">
    <extent class=3D"test.ojb.broker.BookArticle"/>
    <extent class=3D"test.ojb.broker.CdArticle"/>
    <field column=3D"Artikel_Nr" name=3D"articleId"/>
    <field column=3D"Artikelname" name=3D"articleName"/>
    <field column=3D"Lieferanten_Nr" name=3D"supplierId"/>
    <field column=3D"Kategorie_Nr" name=3D"productGroupId"/>
    <field column=3D"Liefereinheit" name=3D"unit"/>
    <field column=3D"Einzelpreis" name=3D"price"/>
    <field column=3D"Lagerbestand" name=3D"stock"/>
    <field column=3D"BestellteEinheiten" name=3D"orderedUnits"/>
    <field column=3D"MindestBestand" name=3D"minimumStock"/>
    <field column=3D"Auslaufartikel" name=3D"isSelloutArticle"/>
    <reference class=3D"test.ojb.broker.ProductGroup" =
name=3D"productGroup"
auto-retrieve=3D"yes">
      <ref-id id=3D"4"/>
    </reference>
  </class>

There is a Database column Artikel_Nr in the Table Artikel.
The Class Article is mapped onto this table. And the attribute =
articleId is
mapped onto the column Artikel_Nr.
That's how I understood Ivans suggestion and I can see no fault in it. =
Maybe
it would be clearer to have the attribute entries defined like follows:
    <attribute name=3D"articleId" column=3D"Artikel_Nr"/>

> If you have to take care of DBMS specialities, like me (using=20
> FrontBase)
> you will definitely want to have different column names than=20
> ivar names.
>=20
> > To do that the table and the class mappings can't go in two=20
> different
> > mappings.=20

Why not?

> That scheme also seems to be hard to maintain -=20
> you'd have to
> > remember making changes two different places.
>=20
> This one I must have overlooked on the original posting. I=20
> totally agree
> with you that maintaining mapping info in two places is=20
> definitely a bad idea.
>=20

This is a point we have to discuss!
If you have a lot of changes to column names you will have to change =
the
column name in two places. Maybe this is too much work.
It would be better to have a reference from attribute descriptions to
columns with a neutral id. like:

in the table description:
<column id=3D"1" type=3D"INTEGER" name=3D"Artikel_Nr" =
primary-key=3D"yes"/>

and in the class description:
<attribute name=3D"articleId" column-ref=3D"1"/>

With this scheme we can separate table and class descriptions but =
maintain
naming information in one place only!

Now you will ask why to keep table and class description in separate =
places?
When I first saw Ivan's proposal I also did not like this separation.
But there is a striking argument:
We can avoid redundant information in the repository this way!
If we have multiple classes mapped onto the same table (for example if =
we
have inheritance mapped in this way) we can keep all information =
regarding
the table structure in one place and don't have to maintain it =
redundantly
in each class description.
For an example see the class descriptions for classes
test.ojb.broker.Article and test.ojb.odmg.Article.
and compare them to the definitions in the 0.5.155 repository.

<thomas/>


> -dirk
>=20
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> http://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>=20