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

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

Hi all,

> -----Urspr=FCngliche Nachricht-----
> Von: Ivan Toshkov [mailto:to...@cr...]
> Gesendet: Mittwoch, 29. August 2001 15:21
> An: Lasse Lindg=E5rd
> Cc: 'Objectbridge (E-Mail)'
> Betreff: RE: [Objectbridge-developers] [Fwd: [objectbridge - Open
> Discussion] New repository.xml/dtd proposal.]
>=20
>=20
> On Wed, 2001-08-29 at 14:34, Lasse Lindg=E5rd wrote:
> > Thomas,
> >=20
> > I think you misunderstood my mail a little.=20
> >=20
> > As I see it we have two use cases that contradict eachother:
> > 1) You can have several classes that map into just one table
> >=20
> > 2) The names of the database collumns is 99% the same as the java
> > properties.
> >=20
> > 1, points to Ivans scheme. 2, points to having just one mapping
> > structure as I propose.
> >=20
> > The way I see it the both cases will potentially produce redundant
> > information.
> > I just feel that the 2nd case will be much more common.
> >=20
> > /Lasse
> >=20
>=20
> Perhaps, I should explain why I proposed this scheme in the=20
> first time:
> I tried to generate the DDL from the current XML structure. As you =
can
> see, most of the data is already there, so there shouldn't be much
> trouble doing that.
>=20
> But most data is not all data! We need to add indexes, size =
attributes
> for jdbc_types and maybe more.
>=20
> Now let's look at the simple example described in repository.xml.
>=20
> $ grep 'table.name' | sort=20
>=20
> produces:
>       <table.name>Artikel</table.name>
>       <table.name>Artikel</table.name>
>       <table.name>BOOKS</table.name>
>       <table.name>CDS</table.name>
>       <table.name>Kategorien</table.name>
>       <table.name>Kategorien</table.name>
>       <table.name>Kategorien</table.name>
>       <table.name>Kategorien</table.name>
>       <table.name>OJB_DLIST_ENTRIES</table.name>
>       <table.name>OJB_DLIST</table.name>
>       <table.name>OJB_DLIST</table.name>
>       <table.name>OJB_DMAP_ENTRIES</table.name>
>       <table.name>OJB_DMAP</table.name>
>       <table.name>OJB_DSET_ENTRIES</table.name>
>       <table.name>OJB_DSET</table.name>
>       <table.name>OJB_NRM</table.name>
>       <table.name>OJB_SEQ</table.name>
>       <table.name>ORDER_POSITION</table.name>
>       <table.name>PRODUCT</table.name>
>       <table.name>PRODUCT</table.name>
>       <table.name>TREEGROUP</table.name>
>       <table.name>TREE</table.name>
>=20
> Which means, 2 classes map to table Artikel, 4 classes map to table
> Kategorien and so on. Actually, there are 22 table descriptions for =
16
> unique tables 37.5% overhead. Currently, we only have three database
> related entries for each field (jdbc_type, column.name and=20
> PrimaryKey).
> Adding two more in a bigger project and you are lost (or at least I =
am
> :).=20
>=20
> Of course, this is not an exhaustive reserch on my part so you don't
> have to put too much fate on my calculations.
>=20
> Perhaps, the best solution will be to support both by XSLT or another
> program?
>=20
> --
> Ivan

I totally agree with Ivan.

OJB aims at beeing a generic persistence solutions for large scale
applications.=20
Having distinct classes mapped onto the same table is quite common (as
Ivan's grep for the simple OJB sample repository shows) and is not an
accident.
Thus we have to provide support for this scenario!

In my eyes it's not so important if it is slightly more difficult to =
write
the repository (I doubt if it really is) because the repository will be
generated by tools. For example Axel Hohaus started working on an =
extension
to ArgoUml to generate the repository directly from an UML =
ClassDiagram!

Thomas

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