objectbridge-developers Mailing List for ObJectRelationalBridge (Page 51)
Brought to you by:
thma
Menu
▾
▴
objectbridge-developers — public list for developer issues
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(14) |
Dec
(20) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(33) |
Feb
(8) |
Mar
(3) |
Apr
(1) |
May
(18) |
Jun
(6) |
Jul
(15) |
Aug
(71) |
Sep
(29) |
Oct
(43) |
Nov
(77) |
Dec
(54) |
| 2002 |
Jan
(54) |
Feb
(147) |
Mar
(144) |
Apr
(163) |
May
(307) |
Jun
(240) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
|
From: Ivan T. <to...@cr...> - 2001-08-31 14:37:08
|
Hi all, Hopefully, I've changed everything as we discussed, added the missing `size' and `nullable' attributes and made the xml a little bit more readable. Please review it, to see if there is something wrong or missing. Especially with the `ref-id' elements, cause I'm not sure I've done them right. Is it correct that `ReferenceDescriptor/descriptor_ids' points to fields in the current class, and for `CollectionDescriptor/descriptor_ids' -- to fields in the referenced class? Also, I see that the method ObjectReferenceDescriptor.getForeignKeyFields() returns a list of ids. I can preserve it's semantics, but I wonder if this is realy needed. -- Ivan |
|
From: <ll...@li...> - 2001-08-29 17:58:40
|
You are right. If the repository is autogenerated then it doesn't matter if the format is a bit too verbose. Thanks /Lasse -----Original Message----- From: obj...@li... [mailto:obj...@li...] On Behalf Of Mahler Thomas Sent: 29. august 2001 15:30 To: 'Ivan Toshkov'; Lasse Lindg=E5rd Cc: 'Objectbridge (E-Mail)' Subject: AW: [Objectbridge-developers] [Fwd: [objectbridge - Open Discussion] New repository.xml/dtd proposal.] 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 _______________________________________________ Objectbridge-developers mailing list Obj...@li... http://lists.sourceforge.net/lists/listinfo/objectbridge-developers |
|
From: Mahler T. <tho...@it...> - 2001-08-29 13:30:18
|
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 |
|
From: Ivan T. <to...@cr...> - 2001-08-29 13:20:59
|
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
Perhaps, I should explain why I proposed this scheme in the 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.
But most data is not all data! We need to add indexes, size attributes
for jdbc_types and maybe more.
Now let's look at the simple example described in repository.xml.
$ grep 'table.name' | sort=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>
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 PrimaryKey).
Adding two more in a bigger project and you are lost (or at least I am
:).=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.
Perhaps, the best solution will be to support both by XSLT or another
program?
--
Ivan
|
|
From: <ll...@li...> - 2001-08-29 11:32:39
|
Thomas,
I think you misunderstood my mail a little.=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
2) The names of the database collumns is 99% the same as the java
properties.
1, points to Ivans scheme. 2, points to having just one mapping
structure as I propose.
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.
/Lasse
-----Original Message-----
From: obj...@li...
[mailto:obj...@li...] On Behalf
Of Mahler Thomas
Sent: 29. august 2001 08:56
To: Objectbridge (E-Mail)
Subject: AW: [Objectbridge-developers] [Fwd: [objectbridge - Open
Discussion] New repository.xml/dtd proposal.]
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
_______________________________________________
Objectbridge-developers mailing list
Obj...@li...
http://lists.sourceforge.net/lists/listinfo/objectbridge-developers
|
|
From: Mahler T. <tho...@it...> - 2001-08-29 08:29:31
|
Hi again, > -----Urspr=FCngliche Nachricht----- > Von: Ivan Toshkov [mailto:to...@cr...] > Gesendet: Mittwoch, 29. August 2001 10:13 > An: Thomas Mahler > Cc: Iv...@ho...; objectbridge > Betreff: Re: [Objectbridge-developers] [Fwd: [objectbridge - Open > Discussion] New repository.xml/dtd proposal.] >=20 >=20 > On Tue, 2001-08-28 at 21:40, Thomas Mahler wrote: > > Hi Ivan,=20 > >=20 > > Thanks for your proposal. It's really an improvement to the old = DTD! > > Very well done! > > I have some minor remarks which you find below. > >=20 > >=20 > > > Subject: [objectbridge - Open Discussion] New repository.xml/dtd > > > proposal. > > > Date: Tue, 28 Aug 2001 07:34:38 -0700 > > > From: no...@so... > > > To: no...@so... > > >=20 > > > Read and respond to this message at: > > > http://sourceforge.net/forum/message.php?msg_id=3D221783 > > > By: core > > >=20 > > > Hello, > > >=20 > > > Here is a proposal for new repository.xml and DTD based on the > > > discussion, which > > > took place in the mailing list. > > >=20 > > > Unfortunately, there are some problems with my email=20 > provider, so I may > > > be not > > > aware of all the recent posts. > > >=20 > >=20 > > I posted your proposal to the mailinglist, so that evryone=20 > listening may > > comment on it. > Thanks. The mail servers seems to operate normaly again :) > >=20 > > > The changes are as follows: > > > 1) Decoupling the repository to the following top-level=20 > elements: > > > jdbc-connection (formerly ConnectionDescriptor), > > > table (formerly part of the ClassDescriptor), > > > class (formerly part of the ClassDescriptor) and > > > class-extension (formerly ClassDescriptor/ExtentDescriptor). > > >=20 > >=20 > > I'd prefer to call it extent, interface or class-extent rather than > > class-extension. > Ok, I'll change that. > >=20 > > > 2) Put all the data in attributes, instead of as text.=20 > This is useful > > > because > > > the DTD can describe the attributes better than the text (e.g. > > > enumeration of > > > values) and it's easer to write SAX parser, because you=20 > can do most of > > > the > > > work in the start event, rather than the end. > > >=20 > >=20 > > I agree. The main reason why I started with an element=20 > oriented DTD was > > that I thought it would be easier to read for humans. But I=20 > think your > > grammar is at least as readable as my original version! > >=20 > > > 3) Changed the naming convention to something, which=20 > more closely > > > resambles > > > the one used by W3C. > > >=20 > >=20 > > It's quite clear to read. What I liked with my old DTD was that the > > element names (say "ClassDescriptor") corresponded with the=20 > respective > > classes that were instantiated by the parser. > > But that's not a real argument... > Well, nither is mine. I wanted one naming convention and I'm=20 > quite used > to the one I proposed, so this is the result. > >=20 > > > One of the remaining issues is the element, formerly=20 > known as (prince? > > > ;)) `deciptor_ids'. It contains a space separated list=20 > of foreign key > > > references. > > > I don't know if this should go to the new `table' or=20 > `class' elements. > > >=20 > >=20 > > Actually the descriptor_ids were referencing the=20 > fielddescriptors of the > > "other" class. Thus we have to use names that identify the=20 > respective > > field element. > > For example: > > <class table-ref=3D"Kategorien" > > name=3D"test.ojb.broker.ProductGroupWithTypedCollection"> > > <field column=3D"Kategorie_Nr" name=3D"groupId"/> > > <field column=3D"KategorieName" name=3D"groupName"/> > > <field column=3D"Beschreibung" name=3D"description"/> > > <collection item-class=3D"test.ojb.broker.Article" > > name=3D"allArticlesInGroup" > > =20 > collection-class=3D"test.ojb.broker.ArticleCollection" > > auto-retrieve=3D"yes" > > auto-update=3D"yes" > > auto-delete=3D"yes"> > > <ref-id id=3D"productGroupId"/> > > </collection> > > </class> > >=20 > > where the 1-n relation between ProductGroup and ARticle is=20 > maintained by > > the foreign key attribute productGroupId in class Article: > > ... > > <field column=3D"Kategorie_Nr" name=3D"productGroupId"/> >=20 > Yes, I was too lazy to change this. Actually, I've generated the XML > from the old one with an XSL (which can post here, once the XML > structure is finalized) and fixed some of the problems=20 > manually. Then I > used JBuilder 5, which can create a DTD from XML and again=20 > fixed *some* > of the problems manually. >=20 > What bothers me with descriptor_ids is that it seems important in = both > class and table elements. In table it will be used to generate the > foreign keys and it should reference to column names. If its in = class, > it should use field names. >=20 > I don't know OJB internals, so I don't know if we can eliminate the > second choice, so perhaps I should eliminate the first one=20 > (as it is in > the proposed xml). >=20 ojb depends on the proper reference to the class-attribute descriptor! = Of course it would be better to have this information only in one place. Thomas >=20 > -- > Ivan >=20 >=20 > _______________________________________________ > Objectbridge-developers mailing list > Obj...@li... > http://lists.sourceforge.net/lists/listinfo/objectbridge-developers >=20 |
|
From: Ivan T. <to...@cr...> - 2001-08-29 08:13:51
|
On Tue, 2001-08-28 at 21:40, Thomas Mahler wrote: > Hi Ivan, > > Thanks for your proposal. It's really an improvement to the old DTD! > Very well done! > I have some minor remarks which you find below. > > > > Subject: [objectbridge - Open Discussion] New repository.xml/dtd > > proposal. > > Date: Tue, 28 Aug 2001 07:34:38 -0700 > > From: no...@so... > > To: no...@so... > > > > Read and respond to this message at: > > http://sourceforge.net/forum/message.php?msg_id=221783 > > By: core > > > > Hello, > > > > Here is a proposal for new repository.xml and DTD based on the > > discussion, which > > took place in the mailing list. > > > > Unfortunately, there are some problems with my email provider, so I may > > be not > > aware of all the recent posts. > > > > I posted your proposal to the mailinglist, so that evryone listening may > comment on it. Thanks. The mail servers seems to operate normaly again :) > > > The changes are as follows: > > 1) Decoupling the repository to the following top-level elements: > > jdbc-connection (formerly ConnectionDescriptor), > > table (formerly part of the ClassDescriptor), > > class (formerly part of the ClassDescriptor) and > > class-extension (formerly ClassDescriptor/ExtentDescriptor). > > > > I'd prefer to call it extent, interface or class-extent rather than > class-extension. Ok, I'll change that. > > > 2) Put all the data in attributes, instead of as text. This is useful > > because > > the DTD can describe the attributes better than the text (e.g. > > enumeration of > > values) and it's easer to write SAX parser, because you can do most of > > the > > work in the start event, rather than the end. > > > > I agree. The main reason why I started with an element oriented DTD was > that I thought it would be easier to read for humans. But I think your > grammar is at least as readable as my original version! > > > 3) Changed the naming convention to something, which more closely > > resambles > > the one used by W3C. > > > > It's quite clear to read. What I liked with my old DTD was that the > element names (say "ClassDescriptor") corresponded with the respective > classes that were instantiated by the parser. > But that's not a real argument... Well, nither is mine. I wanted one naming convention and I'm quite used to the one I proposed, so this is the result. > > > One of the remaining issues is the element, formerly known as (prince? > > ;)) `deciptor_ids'. It contains a space separated list of foreign key > > references. > > I don't know if this should go to the new `table' or `class' elements. > > > > Actually the descriptor_ids were referencing the fielddescriptors of the > "other" class. Thus we have to use names that identify the respective > field element. > For example: > <class table-ref="Kategorien" > name="test.ojb.broker.ProductGroupWithTypedCollection"> > <field column="Kategorie_Nr" name="groupId"/> > <field column="KategorieName" name="groupName"/> > <field column="Beschreibung" name="description"/> > <collection item-class="test.ojb.broker.Article" > name="allArticlesInGroup" > collection-class="test.ojb.broker.ArticleCollection" > auto-retrieve="yes" > auto-update="yes" > auto-delete="yes"> > <ref-id id="productGroupId"/> > </collection> > </class> > > where the 1-n relation between ProductGroup and ARticle is maintained by > the foreign key attribute productGroupId in class Article: > ... > <field column="Kategorie_Nr" name="productGroupId"/> Yes, I was too lazy to change this. Actually, I've generated the XML from the old one with an XSL (which can post here, once the XML structure is finalized) and fixed some of the problems manually. Then I used JBuilder 5, which can create a DTD from XML and again fixed *some* of the problems manually. What bothers me with descriptor_ids is that it seems important in both class and table elements. In table it will be used to generate the foreign keys and it should reference to column names. If its in class, it should use field names. I don't know OJB internals, so I don't know if we can eliminate the second choice, so perhaps I should eliminate the first one (as it is in the proposed xml). -- Ivan |
|
From: Mahler T. <tho...@it...> - 2001-08-29 06:56:41
|
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
|
|
From: Dirk O. <di...@xa...> - 2001-08-29 04:40:21
|
Lasse Lindgård schrieb: > > Something about this strikes me as beeing wrong - or at least > questionable. > > To me a persistence framework must be easy to work with, transperent and > flexible in that order. To me a persistence framework must be flexible, transparent and easy to work with, in that order. So there are obviously different design expectations :-) > It is good to have the flexibility that the mapping files allows. But I > am wondering if the usecase in 99% of the cases is that you just want > the database names to be the same as the ones in the fields. If you have to take care of DBMS specialities, like me (using FrontBase) you will definitely want to have different column names than ivar names. > To do that the table and the class mappings can't go in two different > mappings. That scheme also seems to be hard to maintain - you'd have to > remember making changes two different places. This one I must have overlooked on the original posting. I totally agree with you that maintaining mapping info in two places is definitely a bad idea. -dirk |
|
From: <ll...@li...> - 2001-08-28 23:14:26
|
Something about this strikes me as beeing wrong - or at least questionable. To me a persistence framework must be easy to work with, transperent and flexible in that order. It is good to have the flexibility that the mapping files allows. But I am wondering if the usecase in 99% of the cases is that you just want the database names to be the same as the ones in the fields. - so the database collumn name should be optionable. To do that the table and the class mappings can't go in two different mappings. That scheme also seems to be hard to maintain - you'd have to remember making changes two different places. How about just tossing the table and class mapping into just one xml-block: <mapping class="test.ojb.broker.BookArticle" table="article"> <field javaname="id" collumn="article_id" type="integer"> <field javaname="Price" type="integer"/> </mapping> Price would default to a collumn names price in the database. /Lasse |
|
From: Thomas M. <tho...@ho...> - 2001-08-28 18:16:25
|
Hi Ivan, Thanks for your proposal. It's really an improvement to the old DTD! Very well done! I have some minor remarks which you find below. > Subject: [objectbridge - Open Discussion] New repository.xml/dtd > proposal. > Date: Tue, 28 Aug 2001 07:34:38 -0700 > From: no...@so... > To: no...@so... > > Read and respond to this message at: > http://sourceforge.net/forum/message.php?msg_id=221783 > By: core > > Hello, > > Here is a proposal for new repository.xml and DTD based on the > discussion, which > took place in the mailing list. > > Unfortunately, there are some problems with my email provider, so I may > be not > aware of all the recent posts. > I posted your proposal to the mailinglist, so that evryone listening may comment on it. > The changes are as follows: > 1) Decoupling the repository to the following top-level elements: > jdbc-connection (formerly ConnectionDescriptor), > table (formerly part of the ClassDescriptor), > class (formerly part of the ClassDescriptor) and > class-extension (formerly ClassDescriptor/ExtentDescriptor). > I'd prefer to call it extent, interface or class-extent rather than class-extension. > 2) Put all the data in attributes, instead of as text. This is useful > because > the DTD can describe the attributes better than the text (e.g. > enumeration of > values) and it's easer to write SAX parser, because you can do most of > the > work in the start event, rather than the end. > I agree. The main reason why I started with an element oriented DTD was that I thought it would be easier to read for humans. But I think your grammar is at least as readable as my original version! > 3) Changed the naming convention to something, which more closely > resambles > the one used by W3C. > It's quite clear to read. What I liked with my old DTD was that the element names (say "ClassDescriptor") corresponded with the respective classes that were instantiated by the parser. But that's not a real argument... > One of the remaining issues is the element, formerly known as (prince? > ;)) `deciptor_ids'. It contains a space separated list of foreign key > references. > I don't know if this should go to the new `table' or `class' elements. > Actually the descriptor_ids were referencing the fielddescriptors of the "other" class. Thus we have to use names that identify the respective field element. For example: <class table-ref="Kategorien" name="test.ojb.broker.ProductGroupWithTypedCollection"> <field column="Kategorie_Nr" name="groupId"/> <field column="KategorieName" name="groupName"/> <field column="Beschreibung" name="description"/> <collection item-class="test.ojb.broker.Article" name="allArticlesInGroup" collection-class="test.ojb.broker.ArticleCollection" auto-retrieve="yes" auto-update="yes" auto-delete="yes"> <ref-id id="productGroupId"/> </collection> </class> where the 1-n relation between ProductGroup and ARticle is maintained by the foreign key attribute productGroupId in class Article: ... <field column="Kategorie_Nr" name="productGroupId"/> > Anyway, here is the DTD: > > <?xml version="1.0" encoding="UTF-8" ?> > > <!ELEMENT mapping-repository ( jdbc-connection+, table+, class+, > class-extension* > ) > > > <!ELEMENT jdbc-connection EMPTY > > <!ATTLIST jdbc-connection id ID #REQUIRED > name CDATA #REQUIRED > driver CDATA #REQUIRED > protocol CDATA #REQUIRED > subprotocol CDATA #REQUIRED > dbalias CDATA #REQUIRED > username CDATA #IMPLIED > password CDATA #IMPLIED > > > <!ELEMENT table ( column+ ) > > <!ATTLIST table id ID #REQUIRED > name CDATA #REQUIRED > jdbc-ref IDREF #REQUIRED > > > <!ELEMENT column EMPTY > > <!ATTLIST column name CDATA #REQUIRED > type ( INTEGER | DOUBLE | FLOAT | VARCHAR ) #REQUIRED We will need some more SQL types! These are the types defined by java.sql.Types and are handled properly by OJB: type ( BIT | TINYINT | SMALLINT | INTEGER | BIGINT | DOUBLE | FLOAT | REAL | NUMERIC | DECIMAL | CHAR | VARCHAR | LONGVARCHAR | DATE | TIME | TIMESTAMP | BINARY | VARBINARY | LONGVARBINARY) #REQUIRED > primary-key ( yes | no ) "no" > nullable ( yes | no ) "yes" > indexed ( yes | no ) "no" > size CDATA #IMPLIED > > > <!ELEMENT class ( extent*, field*, reference*, collection* ) > > <!ATTLIST class name ID #REQUIRED > table-ref IDREF #REQUIRED > conversion-strategy CDATA #IMPLIED > proxy CDATA #IMPLIED > > > <!ELEMENT extent EMPTY > > <!ATTLIST extent class CDATA #REQUIRED > > > <!ELEMENT field EMPTY > > <!ATTLIST field name CDATA #REQUIRED > column CDATA #REQUIRED > > > <!ELEMENT reference ( ref-id ) > > <!ATTLIST reference name CDATA #REQUIRED > class NMTOKEN #REQUIRED > auto-retrieve ( yes | no ) "no" I'd prefer to the auto-retrieve default to "yes". As there are almost no situations where you would choose "no"! > auto-update ( yes | no ) "no" > auto-delete ( yes | no ) "no" > > > <!ELEMENT ref-id EMPTY > > <!ATTLIST ref-id id CDATA #REQUIRED > > > <!ELEMENT collection ( ref-id ) > > <!ATTLIST collection name CDATA #REQUIRED > item-class CDATA #REQUIRED > collection-class CDATA #IMPLIED > auto-retrieve ( yes | no ) "no" I'd prefer to the auto-retrieve default to "yes". As there are almost no situations where you would choose "no"! > auto-update ( yes | no ) "no" > auto-delete ( yes | no ) "no" > > > <!ELEMENT class-extension ( extent+ ) > > <!ATTLIST class-extension name CDATA #REQUIRED > > > And here is the repository,xml (which still needs a little work): > > <?xml version="1.0" encoding="UTF-8"?> > <!DOCTYPE mapping-repository SYSTEM "new-rep-gen.dtd"> > > <mapping-repository> > <jdbc-connection dbalias="..\setup\demo.prp" > subprotocol="idb" > protocol="jdbc" > driver="com.lutris.instantdb.jdbc.idbDriver" > name="InstantDB" > id="default"/> > > <jdbc-connection dbalias="dbwte001" > subprotocol="db2" > protocol="jdbc" > driver="COM.ibm.db2.jdbc.app.DB2Driver" > name="db2" > id="db2" > username="db2admin" > password="db2"/> > > <jdbc-connection > dbalias="@(description=(address=(host=127.0.0.1)(protocol=tcp)(port=1521))(conne > ct_data=(sid=orcl)))" > subprotocol="oracle:oci8" > protocol="jdbc" > driver="oracle.jdbc.driver.OracleDriver" > name="oracle" > id="oracle" > username="scott" > password="tiger"/> > > <table id="Artikel" jdbc-ref="default" name="Artikel"> > <column type="INTEGER" name="Artikel_Nr" primary-key="yes"/> > <column type="VARCHAR" name="Artikelname"/> > <column type="INTEGER" name="Lieferanten_Nr"/> > <column type="INTEGER" name="Kategorie_Nr"/> > <column type="VARCHAR" name="Liefereinheit"/> > <column type="FLOAT" name="Einzelpreis"/> > <column type="INTEGER" name="Lagerbestand"/> > <column type="INTEGER" name="BestellteEinheiten"/> > <column type="INTEGER" name="MindestBestand"/> > <column type="INTEGER" name="Auslaufartikel"/> > </table> > > <table id="Kategorien" jdbc-ref="default" name="Kategorien"> > <column type="INTEGER" name="Kategorie_Nr" primary-key="yes"/> > <column type="VARCHAR" name="KategorieName"/> > <column type="VARCHAR" name="Beschreibung"/> > </table> > > <table id="BOOKS" jdbc-ref="default" name="BOOKS"> > <column type="INTEGER" name="Artikel_Nr" primary-key="yes"/> > <column type="VARCHAR" name="Artikelname"/> > <column type="INTEGER" name="Lieferanten_Nr"/> > <column type="INTEGER" name="Kategorie_Nr"/> > <column type="VARCHAR" name="Liefereinheit"/> > <column type="FLOAT" name="Einzelpreis"/> > <column type="INTEGER" name="Lagerbestand"/> > <column type="INTEGER" name="BestellteEinheiten"/> > <column type="INTEGER" name="MindestBestand"/> > <column type="INTEGER" name="Auslaufartikel"/> > <column type="VARCHAR" name="ISBN"/> > <column type="VARCHAR" name="AUTHOR"/> > </table> > > <table id="CDS" jdbc-ref="default" name="CDS"> > <column type="INTEGER" name="Artikel_Nr" primary-key="yes"/> > <column type="VARCHAR" name="Artikelname"/> > <column type="INTEGER" name="Lieferanten_Nr"/> > <column type="INTEGER" name="Kategorie_Nr"/> > <column type="VARCHAR" name="Liefereinheit"/> > <column type="FLOAT" name="Einzelpreis"/> > <column type="INTEGER" name="Lagerbestand"/> > <column type="INTEGER" name="BestellteEinheiten"/> > <column type="INTEGER" name="MindestBestand"/> > <column type="INTEGER" name="Auslaufartikel"/> > <column type="VARCHAR" name="LABEL"/> > <column type="VARCHAR" name="MUSICIANS"/> > </table> > > <table id="ORDER_POSITION" jdbc-ref="default" name="ORDER_POSITION"> > <column type="INTEGER" name="ID" primary-key="yes"/> > <column type="INTEGER" name="ORDER_ID"/> > <column type="INTEGER" name="ARTICLE_ID"/> > </table> > > <table id="TREE" jdbc-ref="default" name="TREE"> > <column type="INTEGER" name="ID" primary-key="yes"/> > <column type="VARCHAR" name="DATA"/> > <column type="INTEGER" name="PARENT_ID"/> > </table> > > <table id="TREEGROUP" jdbc-ref="default" name="TREEGROUP"> > <column type="INTEGER" name="ID" primary-key="yes"/> > <column type="VARCHAR" name="DATA"/> > <column type="INTEGER" name="PARENT_ID"/> > <column type="INTEGER" name="GROUP_ID"/> > </table> > > <table id="PRODUCT" jdbc-ref="default" name="PRODUCT"> > <column type="INTEGER" name="ID" primary-key="yes"/> > <column type="VARCHAR" name="NAME"/> > <column type="DOUBLE" name="PRICE"/> > <column type="INTEGER" name="STOCK"/> > </table> > > <table id="OJB_NRM" jdbc-ref="default" name="OJB_NRM"> > <column type="VARCHAR" name="NAME" primary-key="yes"/> > <column type="VARCHAR" name="OID"/> > </table> > > <table id="OJB_DLIST" jdbc-ref="default" name="OJB_DLIST"> > <column type="INTEGER" name="ID" primary-key="yes"/> > <column type="INTEGER" name="SIZE_"/> > </table> > > <table id="OJB_DLIST_ENTRIES" jdbc-ref="default" > name="OJB_DLIST_ENTRIES"> > <column type="INTEGER" name="ID" primary-key="yes"/> > <column type="INTEGER" name="DLIST_ID"/> > <column type="INTEGER" name="POSITION"/> > <column type="VARCHAR" name="OID"/> > </table> > > <table id="OJB_SEQ" jdbc-ref="default" name="OJB_SEQ"> > <column type="VARCHAR" name="CLASSNAME" primary-key="yes"/> > <column type="VARCHAR" name="FIELDNAME" primary-key="yes"/> > <column type="INTEGER" name="LAST_NUM"/> > </table> > > <table id="OJB_DSET" jdbc-ref="default" name="OJB_DSET"> > <column type="INTEGER" name="ID" primary-key="yes"/> > <column type="INTEGER" name="SIZE_"/> > </table> > > <table id="OJB_DSET_ENTRIES" jdbc-ref="default" > name="OJB_DSET_ENTRIES"> > <column type="INTEGER" name="ID" primary-key="yes"/> > <column type="INTEGER" name="DLIST_ID"/> > <column type="INTEGER" name="POSITION"/> > <column type="VARCHAR" name="OID"/> > </table> > > <table id="OJB_DMAP" jdbc-ref="default" name="OJB_DMAP"> > <column type="INTEGER" name="ID" primary-key="yes"/> > <column type="INTEGER" name="SIZE_"/> > </table> > > <table id="OJB_DMAP_ENTRIES" jdbc-ref="default" > name="OJB_DMAP_ENTRIES"> > <column type="INTEGER" name="ID" primary-key="yes"/> > <column type="INTEGER" name="DMAP_ID"/> > <column type="VARCHAR" name="KEY_OID"/> > <column type="VARCHAR" name="VALUE_OID"/> > </table> > > <class table-ref="Artikel" > name="test.ojb.broker.Article" > conversion-strategy="test.ojb.broker.ArticleConversionStrategy" > proxy="test.ojb.broker.ArticleProxy"> > <extent class="test.ojb.broker.BookArticle"/> > <extent class="test.ojb.broker.CdArticle"/> > <field column="Artikel_Nr" name="articleId"/> > <field column="Artikelname" name="articleName"/> > <field column="Lieferanten_Nr" name="supplierId"/> > <field column="Kategorie_Nr" name="productGroupId"/> > <field column="Liefereinheit" name="unit"/> > <field column="Einzelpreis" name="price"/> > <field column="Lagerbestand" name="stock"/> > <field column="BestellteEinheiten" name="orderedUnits"/> > <field column="MindestBestand" name="minimumStock"/> > <field column="Auslaufartikel" name="isSelloutArticle"/> > <reference class="test.ojb.broker.ProductGroup" name="productGroup" > auto-retrieve="yes"> > <ref-id id="4"/> > </reference> > </class> > > > <class table-ref="Kategorien" > name="test.ojb.broker.ProductGroupWithTypedCollection"> > <field column="Kategorie_Nr" name="groupId"/> > <field column="KategorieName" name="groupName"/> > <field column="Beschreibung" name="description"/> > <collection item-class="test.ojb.broker.Article" > name="allArticlesInGroup" > collection-class="test.ojb.broker.ArticleCollection" > auto-retrieve="yes" > auto-update="yes" > auto-delete="yes"> > <ref-id id="4"/> > </collection> > </class> > > <class table-ref="Kategorien" > name="test.ojb.broker.ProductGroupWithArray"> > <field column="Kategorie_Nr" name="groupId"/> > <field column="KategorieName" name="groupName"/> > <field column="Beschreibung" name="description"/> > <collection item-class="test.ojb.broker.Article" > name="allArticlesInGroup" > auto-retrieve="yes" > auto-update="yes" > auto-delete="yes"> > <ref-id id="4"/> > </collection> > </class> > > <class table-ref="Artikel" name="test.ojb.odmg.Article"> > <field column="Artikel_Nr" name="articleId"/> > <field column="Artikelname" name="articleName"/> > <field column="Lieferanten_Nr" name="supplierId"/> > <field column="Kategorie_Nr" name="productGroupId"/> > <field column="Liefereinheit" name="unit"/> > <field column="Einzelpreis" name="price"/> > <field column="Lagerbestand" name="stock"/> > <field column="BestellteEinheiten" name="orderedUnits"/> > <field column="MindestBestand" name="minimumStock"/> > <field column="Auslaufartikel" name="isSelloutArticle"/> > <reference class="test.ojb.odmg.ProductGroup" name="productGroup" > auto-retrieve="yes"> > <ref-id id="4"/> > </reference> > </class> > > <class table-ref="Kategorien" name="test.ojb.odmg.ProductGroup"> > <field column="Kategorie_Nr" name="groupId"/> > <field column="KategorieName" name="groupName"/> > <field column="Beschreibung" name="description"/> > <collection item-class="test.ojb.odmg.Article" > name="allArticlesInGroup" > auto-retrieve="yes"> > <ref-id id="4"/> > </collection> > </class> > > <class table-ref="BOOKS" name="test.ojb.broker.BookArticle"> > <field column="Artikel_Nr" name="articleId"/> > <field column="Artikelname" name="articleName"/> > <field column="Lieferanten_Nr" name="supplierId"/> > <field column="Kategorie_Nr" name="productGroupId"/> > <field column="Liefereinheit" name="unit"/> > <field column="Einzelpreis" name="price"/> > <field column="Lagerbestand" name="stock"/> > <field column="BestellteEinheiten" name="orderedUnits"/> > <field column="MindestBestand" name="minimumStock"/> > <field column="Auslaufartikel" name="isSelloutArticle"/> > <field column="ISBN" name="isbn"/> > <field column="AUTHOR" name="author"/> > <reference class="test.ojb.broker.ProductGroup" name="productGroup" > auto-retrieve="yes"> > <ref-id id="4"/> > </reference> > </class> > > <class table-ref="CDS" name="test.ojb.broker.CdArticle"> > <field column="Artikel_Nr" name="articleId"/> > <field column="Artikelname" name="articleName"/> > <field column="Lieferanten_Nr" name="supplierId"/> > <field column="Kategorie_Nr" name="productGroupId"/> > <field column="Liefereinheit" name="unit"/> > <field column="Einzelpreis" name="price"/> > <field column="Lagerbestand" name="stock"/> > <field column="BestellteEinheiten" name="orderedUnits"/> > <field column="MindestBestand" name="minimumStock"/> > <field column="Auslaufartikel" name="isSelloutArticle"/> > <field column="LABEL" name="labelname"/> > <field column="MUSICIANS" name="musicians"/> > <reference class="test.ojb.broker.ProductGroup" name="productGroup" > auto-retrieve="yes"> > <ref-id id="4"/> > </reference> > </class> > > <class table-ref="ORDER_POSITION" > name="test.ojb.broker.OrderPosition"> > <field column="ID" name="id"/> > <field column="ORDER_ID" name="order_id"/> > <field column="ARTICLE_ID" name="article_id"/> > <reference class="test.ojb.broker.Article" name="article" > auto-retrieve="yes"> > <ref-id id="3"/> > </reference> > </class> > > <class-extension name="test.ojb.broker.InterfaceArticle"> > <extent class="test.ojb.broker.Article"/> > <extent class="test.ojb.broker.BookArticle"/> > <extent class="test.ojb.broker.CdArticle"/> > </class-extension> > > <class table-ref="TREE" name="test.ojb.broker.Tree"> > <field column="ID" name="id"/> > <field column="DATA" name="data"/> > <field column="PARENT_ID" name="parentId"/> > <collection item-class="test.ojb.broker.Tree" name="childs" > auto-retrieve="yes" > auto-update="yes" auto-delete="yes"> > <ref-id id="3"/> > </collection> > </class> > > <class table-ref="TREEGROUP" name="test.ojb.broker.TreeGroup"> > <field column="ID" name="id"/> > <field column="DATA" name="data"/> > <field column="PARENT_ID" name="parentId"/> > <field column="GROUP_ID" name="groupId"/> > <reference class="test.ojb.broker.TreeGroup" name="myParent" > auto-retrieve="yes"> > <ref-id id="3"/> > </reference> > <reference class="test.ojb.broker.TreeGroup" name="myGroup" > auto-retrieve="yes"> > <ref-id id="4"/> > </reference> > <collection item-class="test.ojb.broker.TreeGroup" name="children" > auto-retrieve="yes" auto-update="yes" auto-delete="yes"> > <ref-id id="3"/> > </collection> > <collection item-class="test.ojb.broker.TreeGroup" > name="groupMembers" > auto-retrieve="yes" auto-update="yes" auto-delete="yes"> > <ref-id id="4"/> > </collection> > </class> > > <class table-ref="PRODUCT" name="test.ojb.tutorial1.Product"> > <field column="ID" name="_id"/> > <field column="NAME" name="name"/> > <field column="PRICE" name="price"/> > <field column="STOCK" name="stock"/> > </class> > > <class table-ref="PRODUCT" name="test.ojb.tutorial2.Product"> > <field column="ID" name="_id"/> > <field column="NAME" name="name"/> > <field column="PRICE" name="price"/> > <field column="STOCK" name="stock"/> > </class> > > <class table-ref="OJB_NRM" name="ojb.odmg.NamedRootsEntry"> > <field column="NAME" name="name"/> > <field column="OID" name="oid"/> > </class> > > <class table-ref="OJB_DLIST" name="ojb.odmg.collections.DListImpl"> > <field column="ID" name="id"/> > <field column="SIZE_" name="size"/> > <collection item-class="ojb.odmg.collections.DListEntry" > name="elements" > auto-retrieve="yes"> > <ref-id id="2"/> > </collection> > </class> > > <class table-ref="OJB_DLIST_ENTRIES" > name="ojb.odmg.collections.DListEntry"> > <field column="ID" name="id"/> > <field column="DLIST_ID" name="dlistId"/> > <field column="POSITION" name="position"/> > <field column="OID" name="serializedOID"/> > </class> > > <class table-ref="OJB_SEQ" name="ojb.broker.SequenceEntry"> > <field column="CLASSNAME" name="classname"/> > <field column="FIELDNAME" name="fieldname"/> > <field column="LAST_NUM" name="current"/> > </class> > > <class table-ref="OJB_DLIST" name="ojb.odmg.collections.DBagImpl"> > <field column="ID" name="id"/> > <field column="SIZE_" name="size"/> > <collection item-class="ojb.odmg.collections.DListEntry" > name="elements" > auto-retrieve="yes"> > <ref-id id="2"/> > </collection> > </class> > > <class table-ref="OJB_DSET" name="ojb.odmg.collections.DSetImpl"> > <field column="ID" name="id"/> > <field column="SIZE_" name="size"/> > <collection item-class="ojb.odmg.collections.DSetEntry" > name="elements" > auto-retrieve="yes"> > <ref-id id="2"/> > </collection> > </class> > > <class table-ref="OJB_DSET_ENTRIES" > name="ojb.odmg.collections.DSetEntry"> > <field column="ID" name="id"/> > <field column="DLIST_ID" name="dlistId"/> > <field column="POSITION" name="position"/> > <field column="OID" name="serializedOID"/> > </class> > > <class table-ref="OJB_DMAP" name="ojb.odmg.collections.DMapImpl"> > <field column="ID" name="id"/> > <field column="SIZE_" name="size"/> > <collection item-class="ojb.odmg.collections.DMapEntry" > name="entries" > auto-retrieve="yes"> > <ref-id id="2"/> > </collection> > </class> > > <class table-ref="OJB_DMAP_ENTRIES" > name="ojb.odmg.collections.DMapEntry"> > <field column="ID" name="id"/> > <field column="DMAP_ID" name="dMapId"/> > <field column="KEY_OID" name="keySerializedOID"/> > <field column="VALUE_OID" name="valueSerializedOID"/> > </class> > </mapping-repository> > > (Hmm, I hope that this can be read) > > Comments are welcome! > I like it. It really clear, concise and human readable! Ivan, you seem to be quite informed about XML. Maybe you also have good ideas to improve the old RepositoryXmlHandler? What I don't like is the enormous switch statement. I already tried to improve readability with the hashtable containing the mapping from element-names to Integers used as identifiers in the switch statement. But it's still not really good object oriented style. Do you have any ideas? <cheers from="thomas"/> > Cheers, > Ivan Toshkov > > ______________________________________________________________________ > You are receiving this email because you elected to monitor this forum. > To stop monitoring this forum, login to SourceForge and visit: > http://sourceforge.net/forum/monitor.php?forum_id=43066 > > _______________________________________________ > Objectbridge-developers mailing list > Obj...@li... > http://lists.sourceforge.net/lists/listinfo/objectbridge-developers |
|
From: Thomas M. <tho...@ho...> - 2001-08-28 17:14:12
|
Hi all, here is an important proposal that Ivan posted to the discussion forum. --thomas -------- Original Message -------- Subject: [objectbridge - Open Discussion] New repository.xml/dtd proposal. Date: Tue, 28 Aug 2001 07:34:38 -0700 From: no...@so... To: no...@so... Read and respond to this message at: http://sourceforge.net/forum/message.php?msg_id=221783 By: core Hello, Here is a proposal for new repository.xml and DTD based on the discussion, which took place in the mailing list. Unfortunately, there are some problems with my email provider, so I may be not aware of all the recent posts. The changes are as follows: 1) Decoupling the repository to the following top-level elements: jdbc-connection (formerly ConnectionDescriptor), table (formerly part of the ClassDescriptor), class (formerly part of the ClassDescriptor) and class-extension (formerly ClassDescriptor/ExtentDescriptor). 2) Put all the data in attributes, instead of as text. This is useful because the DTD can describe the attributes better than the text (e.g. enumeration of values) and it's easer to write SAX parser, because you can do most of the work in the start event, rather than the end. 3) Changed the naming convention to something, which more closely resambles the one used by W3C. One of the remaining issues is the element, formerly known as (prince? ;)) `deciptor_ids'. It contains a space separated list of foreign key references. I don't know if this should go to the new `table' or `class' elements. Anyway, here is the DTD: <?xml version="1.0" encoding="UTF-8" ?> <!ELEMENT mapping-repository ( jdbc-connection+, table+, class+, class-extension* ) > <!ELEMENT jdbc-connection EMPTY > <!ATTLIST jdbc-connection id ID #REQUIRED name CDATA #REQUIRED driver CDATA #REQUIRED protocol CDATA #REQUIRED subprotocol CDATA #REQUIRED dbalias CDATA #REQUIRED username CDATA #IMPLIED password CDATA #IMPLIED > <!ELEMENT table ( column+ ) > <!ATTLIST table id ID #REQUIRED name CDATA #REQUIRED jdbc-ref IDREF #REQUIRED > <!ELEMENT column EMPTY > <!ATTLIST column name CDATA #REQUIRED type ( INTEGER | DOUBLE | FLOAT | VARCHAR ) #REQUIRED primary-key ( yes | no ) "no" nullable ( yes | no ) "yes" indexed ( yes | no ) "no" size CDATA #IMPLIED > <!ELEMENT class ( extent*, field*, reference*, collection* ) > <!ATTLIST class name ID #REQUIRED table-ref IDREF #REQUIRED conversion-strategy CDATA #IMPLIED proxy CDATA #IMPLIED > <!ELEMENT extent EMPTY > <!ATTLIST extent class CDATA #REQUIRED > <!ELEMENT field EMPTY > <!ATTLIST field name CDATA #REQUIRED column CDATA #REQUIRED > <!ELEMENT reference ( ref-id ) > <!ATTLIST reference name CDATA #REQUIRED class NMTOKEN #REQUIRED auto-retrieve ( yes | no ) "no" auto-update ( yes | no ) "no" auto-delete ( yes | no ) "no" > <!ELEMENT ref-id EMPTY > <!ATTLIST ref-id id CDATA #REQUIRED > <!ELEMENT collection ( ref-id ) > <!ATTLIST collection name CDATA #REQUIRED item-class CDATA #REQUIRED collection-class CDATA #IMPLIED auto-retrieve ( yes | no ) "no" auto-update ( yes | no ) "no" auto-delete ( yes | no ) "no" > <!ELEMENT class-extension ( extent+ ) > <!ATTLIST class-extension name CDATA #REQUIRED > And here is the repository,xml (which still needs a little work): <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE mapping-repository SYSTEM "new-rep-gen.dtd"> <mapping-repository> <jdbc-connection dbalias="..\setup\demo.prp" subprotocol="idb" protocol="jdbc" driver="com.lutris.instantdb.jdbc.idbDriver" name="InstantDB" id="default"/> <jdbc-connection dbalias="dbwte001" subprotocol="db2" protocol="jdbc" driver="COM.ibm.db2.jdbc.app.DB2Driver" name="db2" id="db2" username="db2admin" password="db2"/> <jdbc-connection dbalias="@(description=(address=(host=127.0.0.1)(protocol=tcp)(port=1521))(conne ct_data=(sid=orcl)))" subprotocol="oracle:oci8" protocol="jdbc" driver="oracle.jdbc.driver.OracleDriver" name="oracle" id="oracle" username="scott" password="tiger"/> <table id="Artikel" jdbc-ref="default" name="Artikel"> <column type="INTEGER" name="Artikel_Nr" primary-key="yes"/> <column type="VARCHAR" name="Artikelname"/> <column type="INTEGER" name="Lieferanten_Nr"/> <column type="INTEGER" name="Kategorie_Nr"/> <column type="VARCHAR" name="Liefereinheit"/> <column type="FLOAT" name="Einzelpreis"/> <column type="INTEGER" name="Lagerbestand"/> <column type="INTEGER" name="BestellteEinheiten"/> <column type="INTEGER" name="MindestBestand"/> <column type="INTEGER" name="Auslaufartikel"/> </table> <table id="Kategorien" jdbc-ref="default" name="Kategorien"> <column type="INTEGER" name="Kategorie_Nr" primary-key="yes"/> <column type="VARCHAR" name="KategorieName"/> <column type="VARCHAR" name="Beschreibung"/> </table> <table id="BOOKS" jdbc-ref="default" name="BOOKS"> <column type="INTEGER" name="Artikel_Nr" primary-key="yes"/> <column type="VARCHAR" name="Artikelname"/> <column type="INTEGER" name="Lieferanten_Nr"/> <column type="INTEGER" name="Kategorie_Nr"/> <column type="VARCHAR" name="Liefereinheit"/> <column type="FLOAT" name="Einzelpreis"/> <column type="INTEGER" name="Lagerbestand"/> <column type="INTEGER" name="BestellteEinheiten"/> <column type="INTEGER" name="MindestBestand"/> <column type="INTEGER" name="Auslaufartikel"/> <column type="VARCHAR" name="ISBN"/> <column type="VARCHAR" name="AUTHOR"/> </table> <table id="CDS" jdbc-ref="default" name="CDS"> <column type="INTEGER" name="Artikel_Nr" primary-key="yes"/> <column type="VARCHAR" name="Artikelname"/> <column type="INTEGER" name="Lieferanten_Nr"/> <column type="INTEGER" name="Kategorie_Nr"/> <column type="VARCHAR" name="Liefereinheit"/> <column type="FLOAT" name="Einzelpreis"/> <column type="INTEGER" name="Lagerbestand"/> <column type="INTEGER" name="BestellteEinheiten"/> <column type="INTEGER" name="MindestBestand"/> <column type="INTEGER" name="Auslaufartikel"/> <column type="VARCHAR" name="LABEL"/> <column type="VARCHAR" name="MUSICIANS"/> </table> <table id="ORDER_POSITION" jdbc-ref="default" name="ORDER_POSITION"> <column type="INTEGER" name="ID" primary-key="yes"/> <column type="INTEGER" name="ORDER_ID"/> <column type="INTEGER" name="ARTICLE_ID"/> </table> <table id="TREE" jdbc-ref="default" name="TREE"> <column type="INTEGER" name="ID" primary-key="yes"/> <column type="VARCHAR" name="DATA"/> <column type="INTEGER" name="PARENT_ID"/> </table> <table id="TREEGROUP" jdbc-ref="default" name="TREEGROUP"> <column type="INTEGER" name="ID" primary-key="yes"/> <column type="VARCHAR" name="DATA"/> <column type="INTEGER" name="PARENT_ID"/> <column type="INTEGER" name="GROUP_ID"/> </table> <table id="PRODUCT" jdbc-ref="default" name="PRODUCT"> <column type="INTEGER" name="ID" primary-key="yes"/> <column type="VARCHAR" name="NAME"/> <column type="DOUBLE" name="PRICE"/> <column type="INTEGER" name="STOCK"/> </table> <table id="OJB_NRM" jdbc-ref="default" name="OJB_NRM"> <column type="VARCHAR" name="NAME" primary-key="yes"/> <column type="VARCHAR" name="OID"/> </table> <table id="OJB_DLIST" jdbc-ref="default" name="OJB_DLIST"> <column type="INTEGER" name="ID" primary-key="yes"/> <column type="INTEGER" name="SIZE_"/> </table> <table id="OJB_DLIST_ENTRIES" jdbc-ref="default" name="OJB_DLIST_ENTRIES"> <column type="INTEGER" name="ID" primary-key="yes"/> <column type="INTEGER" name="DLIST_ID"/> <column type="INTEGER" name="POSITION"/> <column type="VARCHAR" name="OID"/> </table> <table id="OJB_SEQ" jdbc-ref="default" name="OJB_SEQ"> <column type="VARCHAR" name="CLASSNAME" primary-key="yes"/> <column type="VARCHAR" name="FIELDNAME" primary-key="yes"/> <column type="INTEGER" name="LAST_NUM"/> </table> <table id="OJB_DSET" jdbc-ref="default" name="OJB_DSET"> <column type="INTEGER" name="ID" primary-key="yes"/> <column type="INTEGER" name="SIZE_"/> </table> <table id="OJB_DSET_ENTRIES" jdbc-ref="default" name="OJB_DSET_ENTRIES"> <column type="INTEGER" name="ID" primary-key="yes"/> <column type="INTEGER" name="DLIST_ID"/> <column type="INTEGER" name="POSITION"/> <column type="VARCHAR" name="OID"/> </table> <table id="OJB_DMAP" jdbc-ref="default" name="OJB_DMAP"> <column type="INTEGER" name="ID" primary-key="yes"/> <column type="INTEGER" name="SIZE_"/> </table> <table id="OJB_DMAP_ENTRIES" jdbc-ref="default" name="OJB_DMAP_ENTRIES"> <column type="INTEGER" name="ID" primary-key="yes"/> <column type="INTEGER" name="DMAP_ID"/> <column type="VARCHAR" name="KEY_OID"/> <column type="VARCHAR" name="VALUE_OID"/> </table> <class table-ref="Artikel" name="test.ojb.broker.Article" conversion-strategy="test.ojb.broker.ArticleConversionStrategy" proxy="test.ojb.broker.ArticleProxy"> <extent class="test.ojb.broker.BookArticle"/> <extent class="test.ojb.broker.CdArticle"/> <field column="Artikel_Nr" name="articleId"/> <field column="Artikelname" name="articleName"/> <field column="Lieferanten_Nr" name="supplierId"/> <field column="Kategorie_Nr" name="productGroupId"/> <field column="Liefereinheit" name="unit"/> <field column="Einzelpreis" name="price"/> <field column="Lagerbestand" name="stock"/> <field column="BestellteEinheiten" name="orderedUnits"/> <field column="MindestBestand" name="minimumStock"/> <field column="Auslaufartikel" name="isSelloutArticle"/> <reference class="test.ojb.broker.ProductGroup" name="productGroup" auto-retrieve="yes"> <ref-id id="4"/> </reference> </class> <class table-ref="Kategorien" name="test.ojb.broker.ProductGroup" proxy="test.ojb.broker.ProductGroupProxy"> <field column="Kategorie_Nr" name="groupId"/> <field column="KategorieName" name="groupName"/> <field column="Beschreibung" name="description"/> <collection item-class="test.ojb.broker.Article" name="allArticlesInGroup" auto-retrieve="yes"> <ref-id id="4"/> </collection> </class> <class table-ref="Kategorien" name="test.ojb.broker.ProductGroupWithTypedCollection"> <field column="Kategorie_Nr" name="groupId"/> <field column="KategorieName" name="groupName"/> <field column="Beschreibung" name="description"/> <collection item-class="test.ojb.broker.Article" name="allArticlesInGroup" collection-class="test.ojb.broker.ArticleCollection" auto-retrieve="yes" auto-update="yes" auto-delete="yes"> <ref-id id="4"/> </collection> </class> <class table-ref="Kategorien" name="test.ojb.broker.ProductGroupWithArray"> <field column="Kategorie_Nr" name="groupId"/> <field column="KategorieName" name="groupName"/> <field column="Beschreibung" name="description"/> <collection item-class="test.ojb.broker.Article" name="allArticlesInGroup" auto-retrieve="yes" auto-update="yes" auto-delete="yes"> <ref-id id="4"/> </collection> </class> <class table-ref="Artikel" name="test.ojb.odmg.Article"> <field column="Artikel_Nr" name="articleId"/> <field column="Artikelname" name="articleName"/> <field column="Lieferanten_Nr" name="supplierId"/> <field column="Kategorie_Nr" name="productGroupId"/> <field column="Liefereinheit" name="unit"/> <field column="Einzelpreis" name="price"/> <field column="Lagerbestand" name="stock"/> <field column="BestellteEinheiten" name="orderedUnits"/> <field column="MindestBestand" name="minimumStock"/> <field column="Auslaufartikel" name="isSelloutArticle"/> <reference class="test.ojb.odmg.ProductGroup" name="productGroup" auto-retrieve="yes"> <ref-id id="4"/> </reference> </class> <class table-ref="Kategorien" name="test.ojb.odmg.ProductGroup"> <field column="Kategorie_Nr" name="groupId"/> <field column="KategorieName" name="groupName"/> <field column="Beschreibung" name="description"/> <collection item-class="test.ojb.odmg.Article" name="allArticlesInGroup" auto-retrieve="yes"> <ref-id id="4"/> </collection> </class> <class table-ref="BOOKS" name="test.ojb.broker.BookArticle"> <field column="Artikel_Nr" name="articleId"/> <field column="Artikelname" name="articleName"/> <field column="Lieferanten_Nr" name="supplierId"/> <field column="Kategorie_Nr" name="productGroupId"/> <field column="Liefereinheit" name="unit"/> <field column="Einzelpreis" name="price"/> <field column="Lagerbestand" name="stock"/> <field column="BestellteEinheiten" name="orderedUnits"/> <field column="MindestBestand" name="minimumStock"/> <field column="Auslaufartikel" name="isSelloutArticle"/> <field column="ISBN" name="isbn"/> <field column="AUTHOR" name="author"/> <reference class="test.ojb.broker.ProductGroup" name="productGroup" auto-retrieve="yes"> <ref-id id="4"/> </reference> </class> <class table-ref="CDS" name="test.ojb.broker.CdArticle"> <field column="Artikel_Nr" name="articleId"/> <field column="Artikelname" name="articleName"/> <field column="Lieferanten_Nr" name="supplierId"/> <field column="Kategorie_Nr" name="productGroupId"/> <field column="Liefereinheit" name="unit"/> <field column="Einzelpreis" name="price"/> <field column="Lagerbestand" name="stock"/> <field column="BestellteEinheiten" name="orderedUnits"/> <field column="MindestBestand" name="minimumStock"/> <field column="Auslaufartikel" name="isSelloutArticle"/> <field column="LABEL" name="labelname"/> <field column="MUSICIANS" name="musicians"/> <reference class="test.ojb.broker.ProductGroup" name="productGroup" auto-retrieve="yes"> <ref-id id="4"/> </reference> </class> <class table-ref="ORDER_POSITION" name="test.ojb.broker.OrderPosition"> <field column="ID" name="id"/> <field column="ORDER_ID" name="order_id"/> <field column="ARTICLE_ID" name="article_id"/> <reference class="test.ojb.broker.Article" name="article" auto-retrieve="yes"> <ref-id id="3"/> </reference> </class> <class-extension name="test.ojb.broker.InterfaceArticle"> <extent class="test.ojb.broker.Article"/> <extent class="test.ojb.broker.BookArticle"/> <extent class="test.ojb.broker.CdArticle"/> </class-extension> <class table-ref="TREE" name="test.ojb.broker.Tree"> <field column="ID" name="id"/> <field column="DATA" name="data"/> <field column="PARENT_ID" name="parentId"/> <collection item-class="test.ojb.broker.Tree" name="childs" auto-retrieve="yes" auto-update="yes" auto-delete="yes"> <ref-id id="3"/> </collection> </class> <class table-ref="TREEGROUP" name="test.ojb.broker.TreeGroup"> <field column="ID" name="id"/> <field column="DATA" name="data"/> <field column="PARENT_ID" name="parentId"/> <field column="GROUP_ID" name="groupId"/> <reference class="test.ojb.broker.TreeGroup" name="myParent" auto-retrieve="yes"> <ref-id id="3"/> </reference> <reference class="test.ojb.broker.TreeGroup" name="myGroup" auto-retrieve="yes"> <ref-id id="4"/> </reference> <collection item-class="test.ojb.broker.TreeGroup" name="children" auto-retrieve="yes" auto-update="yes" auto-delete="yes"> <ref-id id="3"/> </collection> <collection item-class="test.ojb.broker.TreeGroup" name="groupMembers" auto-retrieve="yes" auto-update="yes" auto-delete="yes"> <ref-id id="4"/> </collection> </class> <class table-ref="PRODUCT" name="test.ojb.tutorial1.Product"> <field column="ID" name="_id"/> <field column="NAME" name="name"/> <field column="PRICE" name="price"/> <field column="STOCK" name="stock"/> </class> <class table-ref="PRODUCT" name="test.ojb.tutorial2.Product"> <field column="ID" name="_id"/> <field column="NAME" name="name"/> <field column="PRICE" name="price"/> <field column="STOCK" name="stock"/> </class> <class table-ref="OJB_NRM" name="ojb.odmg.NamedRootsEntry"> <field column="NAME" name="name"/> <field column="OID" name="oid"/> </class> <class table-ref="OJB_DLIST" name="ojb.odmg.collections.DListImpl"> <field column="ID" name="id"/> <field column="SIZE_" name="size"/> <collection item-class="ojb.odmg.collections.DListEntry" name="elements" auto-retrieve="yes"> <ref-id id="2"/> </collection> </class> <class table-ref="OJB_DLIST_ENTRIES" name="ojb.odmg.collections.DListEntry"> <field column="ID" name="id"/> <field column="DLIST_ID" name="dlistId"/> <field column="POSITION" name="position"/> <field column="OID" name="serializedOID"/> </class> <class table-ref="OJB_SEQ" name="ojb.broker.SequenceEntry"> <field column="CLASSNAME" name="classname"/> <field column="FIELDNAME" name="fieldname"/> <field column="LAST_NUM" name="current"/> </class> <class table-ref="OJB_DLIST" name="ojb.odmg.collections.DBagImpl"> <field column="ID" name="id"/> <field column="SIZE_" name="size"/> <collection item-class="ojb.odmg.collections.DListEntry" name="elements" auto-retrieve="yes"> <ref-id id="2"/> </collection> </class> <class table-ref="OJB_DSET" name="ojb.odmg.collections.DSetImpl"> <field column="ID" name="id"/> <field column="SIZE_" name="size"/> <collection item-class="ojb.odmg.collections.DSetEntry" name="elements" auto-retrieve="yes"> <ref-id id="2"/> </collection> </class> <class table-ref="OJB_DSET_ENTRIES" name="ojb.odmg.collections.DSetEntry"> <field column="ID" name="id"/> <field column="DLIST_ID" name="dlistId"/> <field column="POSITION" name="position"/> <field column="OID" name="serializedOID"/> </class> <class table-ref="OJB_DMAP" name="ojb.odmg.collections.DMapImpl"> <field column="ID" name="id"/> <field column="SIZE_" name="size"/> <collection item-class="ojb.odmg.collections.DMapEntry" name="entries" auto-retrieve="yes"> <ref-id id="2"/> </collection> </class> <class table-ref="OJB_DMAP_ENTRIES" name="ojb.odmg.collections.DMapEntry"> <field column="ID" name="id"/> <field column="DMAP_ID" name="dMapId"/> <field column="KEY_OID" name="keySerializedOID"/> <field column="VALUE_OID" name="valueSerializedOID"/> </class> </mapping-repository> (Hmm, I hope that this can be read) Comments are welcome! Cheers, Ivan Toshkov ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge and visit: http://sourceforge.net/forum/monitor.php?forum_id=43066 |
|
From: Ivan T. <to...@cr...> - 2001-08-28 12:16:10
|
On Mon, 2001-08-27 at 15:05, Mahler Thomas wrote: > Now my question to everyone working with OJB: > What do you prefer? > 1. Allow remote calls that access the metadata repository, cache, etc.? This > would require to include all these calls being added to the Request protocol > (and to implement them in the RequestHandler) > 2. Expose only the PersistenceBroker API as suggested by implementation. > This will keep the design clear. But it will be impossible to make explicit > changes to the metadata etc. > > Personally I vote for option two. But I'd like to hear your suggestions, as > I don't know if you are already building applications that rely on changes > to metadata etc. > I too vote for option two. Franky, I can't quite imagine what kind of application would need the flexibility of option one, except perhaps a development environment, which knows about and supports OJB. And even in this case it has alternatives. Ivan |
|
From: Mahler T. <tho...@it...> - 2001-08-27 13:21:18
|
Hi Sascha, hi all, > > Read and respond to this message at: > http://sourceforge.net/forum/message.php?msg_id=214023 > By: koenig > > Hi, > > the new version (ojb-0.5.150.jar or higher) creates a file > ojb.broker.PesistenceBrokerFactoryConfiguration.properties. This file contains config data for the factory Class PersistenceBrokerFactory (used to obtain PersistenceBroker objects). > This file is created > after the first run and sets the attribute > 'repositoryFile=repository.xml'. > This overrides an explicit specification of the repository > file via the call > 'DescriptorRepository.setRepositoryPath(databaseURL)'. > > Setting the repositoryFile attribute in the properties file > to the desired file > fixes the problem. It's both: bug and feature! I'm not sure how to deal with this problem. On the on hand we have the DescriptorRepository.setRepositoryPath() method to explicitly set the repository. On the other hand I want to use the PersistenceBrokerFactory to produce PersistenceBroker objects. This factory is helpful to provide the application with PersistenceBrokerImpls (in the local scenario) or with PersistenceBrokerClients used in the client/server scenario. The client/server scenario drastically changes the programming model for OJB programmers, as you cannot access all aspects of OJB through direct method calls within the same VM but only through Reuqests to the PersistenceBrokerServer. Currently the PersistenceBroker server can only handle requests that correspond to the PersistenceBroker interface. I.E. there are no requests possible that modify the repository, objectcache, etc. Now my question to everyone working with OJB: What do you prefer? 1. Allow remote calls that access the metadata repository, cache, etc.? This would require to include all these calls being added to the Request protocol (and to implement them in the RequestHandler) 2. Expose only the PersistenceBroker API as suggested by implementation. This will keep the design clear. But it will be impossible to make explicit changes to the metadata etc. Personally I vote for option two. But I'd like to hear your suggestions, as I don't know if you are already building applications that rely on changes to metadata etc. <thomas/> > > Sascha > > > > __________________________ > Sascha A. Koenig > CCS-1, MS T006 > Computer and Computational Sciences > Los Alamos National Laboratory > Los Alamos, NM 87545 > > phone: +1 (505) 663-5217 cellular: +1 (505) 670-4643 > fax: +1 (505) 665-4939 http://www.OpenEMed.org > > > ______________________________________________________________________ > You are receiving this email because you elected to monitor > this forum. > To stop monitoring this forum, login to SourceForge and visit: > http://sourceforge.net/forum/monitor.php?forum_id=43066 > |
|
From: <ll...@li...> - 2001-08-26 17:03:50
|
Yeah. You are right there. The formats are too unestablished to depend on. It would be pretty easy to generate a XSLT program that can transform between the two formats. Then the castor tools would be applicable to ObJectBridge. Once I get to know the format better, I might be able to produce such a stylesheet. Then I could contribute the stylesheet to the castor tools as an objectbridge extension. /Lasse -----Original Message----- From: obj...@li... [mailto:obj...@li...] On Behalf Of Thomas Mahler Sent: 1. januar 1997 00:30 To: Lasse Lindg=E5rd Cc: obj...@li... Subject: Re: AW: AW: [Objectbridge-developers] generating mapping files and da taba ses Hi Lasse, Lasse Lindg=E5rd wrote: >=20 > Have you looked at the http://castor.exolab.org format for mapping files > ?? >=20 > As far as I can read from their mailing list several project exists that > can generate castor mapping files. DDL programs also exists. >=20 > I don't know castor JDO that well, but I looked at the mapping files and > they look pretty much the same contentwise as the objectbridge ones. >=20 > Wouldn't that be better than reinventing the wheel ? Sure the best thing would be to have a standardized DTD for O/R mappings. There are also some attempts in this direction (see for example Jon Garfunkels LORAX project http://www.coopdata.net/software/lorax/). There is also XMI which tries to be a unifed standard for UML models... There is also a DTD for describing mappings in JDO... But I none of these attempts has succeeded as a generally accepted standard. I also had a look at the Castor DTD. Of course it has things in it we could reuse. But it's all so intermixed with stuff for XML mapping, LDAP access, etc. that I won't like to have it as grammar for describing O/R mapping. Sure it would be great to have an O/R mappings interchangeable between both tools! =20 So long as there is no standard I guess the best thing we can do is to have a very simple DTD that fits all OJB mapping needs and nothing more. This will keep parsing simple. Once there is an established standard we can easily adopt to it. --Thomas >=20 > /Lasse >=20 > _______________________________________________ > Objectbridge-developers mailing list > Obj...@li... > http://lists.sourceforge.net/lists/listinfo/objectbridge-developers _______________________________________________ Objectbridge-developers mailing list Obj...@li... http://lists.sourceforge.net/lists/listinfo/objectbridge-developers |
|
From: Thomas M. <tho...@ho...> - 2001-08-26 10:20:39
|
Hi Lasse, Lasse Lindg=E5rd wrote: > = > Have you looked at the http://castor.exolab.org format for mapping file= s > ?? > = > As far as I can read from their mailing list several project exists tha= t > can generate castor mapping files. DDL programs also exists. > = > I don't know castor JDO that well, but I looked at the mapping files an= d > they look pretty much the same contentwise as the objectbridge ones. > = > Wouldn't that be better than reinventing the wheel ? Sure the best thing would be to have a standardized DTD for O/R mappings. There are also some attempts in this direction (see for example Jon Garfunkels LORAX project http://www.coopdata.net/software/lorax/). There is also XMI which tries to be a unifed standard for UML models... There is also a DTD for describing mappings in JDO... But I none of these attempts has succeeded as a generally accepted standard. I also had a look at the Castor DTD. Of course it has things in it we could reuse. But it's all so intermixed with stuff for XML mapping, LDAP access, etc. that I won't like to have it as grammar for describing O/R mapping. Sure it would be great to have an O/R mappings interchangeable between both tools! = So long as there is no standard I guess the best thing we can do is to have a very simple DTD that fits all OJB mapping needs and nothing more. This will keep parsing simple. Once there is an established standard we can easily adopt to it. --Thomas > = > /Lasse > = > _______________________________________________ > Objectbridge-developers mailing list > Obj...@li... > http://lists.sourceforge.net/lists/listinfo/objectbridge-developers |
|
From: <ll...@li...> - 2001-08-24 12:50:00
|
Have you looked at the http://castor.exolab.org format for mapping files ?? As far as I can read from their mailing list several project exists that can generate castor mapping files. DDL programs also exists. I don't know castor JDO that well, but I looked at the mapping files and they look pretty much the same contentwise as the objectbridge ones. Wouldn't that be better than reinventing the wheel ? /Lasse |
|
From: Ivan T. <to...@cr...> - 2001-08-24 10:48:23
|
On Fri, 2001-08-24 at 12:47, Mahler Thomas wrote: > Hi again, >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Ivan Toshkov [mailto:to...@cr...] > > Gesendet: Donnerstag, 23. August 2001 17:14 > > An: Mahler Thomas > > Cc: 'Lasse Lindg=E5rd'; obj...@li... > > Betreff: Re: AW: AW: [Objectbridge-developers] generating=20 > > mapping files > > and da taba ses > >=20 > >=20 > > On Thu, 2001-08-23 at 16:40, Mahler Thomas wrote: > > > > Unfortunately, there isn't quite enough data in the=20 > > > > repository.xml file > > > > to generate the correct SQL statements. So far, I don't=20 > > know when to > > > > generate 'NOT NULL' and the size of VARCHAR objects. > > > >=20 > > > > So, perhaps we should add this data to the XML? > > > >=20 > > >=20 > > > Yes I have been thinking in this direction too. > >=20 > > Ok, I've added the following two attributes to jdbc_type:=20 > > 'not-null' and > > 'size'. The problem is that (even in the test repository) many tables > > are described in several places each, which can lead to inconsitency. > > So, what do you think of the following form? > >=20 > > <MappingRepository> > > <JdbcConnectionDescriptor id=3D"default"> > > ... > > </JdbcConnectionDescriptor> > > <JdbcConnectionDescriptor id=3D"other"> > > ... > > </JdbcConnectionDescriptor> > > ... >=20 > I like this idea to keep the JdbcConnectionDescriptors out of the > ClassDescriptors! >=20 > > <TableDescriptor name=3D"table_name" id=3D"tableId" > > [jdbc-ref=3D"other"]> > > <ColumnDescriptor name=3D"columnName" [primaryKey=3D"yes|no"] > > [not-null=3D"yes|no"] .../> > > </TableDescriptor> > > ... >=20 > it's also good to have tables separately described from classes, as sever= al > classes may be mapped to the same table! > I think we need some more information for jdbc_type, as size works only f= or > CHAR(X) and VARCHAR(Y), but there are also things like DECIMAL(6,2) or > NUMERIC(3,8) allowed in SQL ! > Well, this may not be the best solution, but size=3D"3, 8" could do the trick. Of course, if there is more information needed, we should put it. > Maybe it's also a good idea to have a switch [indexed=3D"yes|no"]. This w= ould > allow to generate indexes on certain columns that are used in where claus= es. >=20 Sure! |
|
From: Mahler T. <tho...@it...> - 2001-08-24 10:35:15
|
Hi again, > -----Urspr=FCngliche Nachricht----- > Von: Ivan Toshkov [mailto:to...@cr...] > Gesendet: Donnerstag, 23. August 2001 17:14 > An: Mahler Thomas > Cc: 'Lasse Lindg=E5rd'; obj...@li... > Betreff: Re: AW: AW: [Objectbridge-developers] generating=20 > mapping files > and da taba ses >=20 >=20 > On Thu, 2001-08-23 at 16:40, Mahler Thomas wrote: > > > Unfortunately, there isn't quite enough data in the=20 > > > repository.xml file > > > to generate the correct SQL statements. So far, I don't=20 > know when to > > > generate 'NOT NULL' and the size of VARCHAR objects. > > >=20 > > > So, perhaps we should add this data to the XML? > > >=20 > >=20 > > Yes I have been thinking in this direction too. >=20 > Ok, I've added the following two attributes to jdbc_type:=20 > 'not-null' and > 'size'. The problem is that (even in the test repository) many = tables > are described in several places each, which can lead to inconsitency. > So, what do you think of the following form? >=20 > <MappingRepository> > <JdbcConnectionDescriptor id=3D"default"> > ... > </JdbcConnectionDescriptor> > <JdbcConnectionDescriptor id=3D"other"> > ... > </JdbcConnectionDescriptor> > ... I like this idea to keep the JdbcConnectionDescriptors out of the ClassDescriptors! > <TableDescriptor name=3D"table_name" id=3D"tableId" > [jdbc-ref=3D"other"]> > <ColumnDescriptor name=3D"columnName" [primaryKey=3D"yes|no"] > [not-null=3D"yes|no"] .../> > </TableDescriptor> > ... it's also good to have tables separately described from classes, as = several classes may be mapped to the same table! I think we need some more information for jdbc_type, as size works only = for CHAR(X) and VARCHAR(Y), but there are also things like DECIMAL(6,2) or NUMERIC(3,8) allowed in SQL ! Maybe it's also a good idea to have a switch [indexed=3D"yes|no"]. This = would allow to generate indexes on certain columns that are used in where = clauses. > <ClassDescriptor [table-ref=3D"tableId"]> > ... > <FieldDescriptor [column-name=3D"columnName"]> > ... > </FieldDescriptor> > </ClassDescriptor> > </MappingRepository> >=20 >=20 >=20 |
|
From: Axel H. <axe...@ar...> - 2001-08-23 15:48:10
|
Hi Ivan, the input of my projekt is an UML-classdiagram in ArgoUml. That's by base information. Output is a repository.xml, generate.dll (SQL-statements to create te database) and java-files for entity-class, proxy-class and interface. cheers axel -----Urspr=FCngliche Nachricht----- Von: Ivan Toshkov [mailto:to...@cr...]=20 Gesendet: Donnerstag, 23. August 2001 17:40 An: Axel Hohaus Cc: obj...@li... Betreff: Re: [Objectbridge-developers] Generating Great! I'm working on a DDL generator from repository.xml. Perhaps we'll be able share some code and ideas. Could you describe what are the inputs and outputs of your project? Cheers, Ivan |
|
From: Ivan T. <to...@cr...> - 2001-08-23 15:40:58
|
Great! I'm working on a DDL generator from repository.xml. Perhaps we'll be able share some code and ideas. Could you describe what are the inputs and outputs of your project? Cheers, Ivan |
|
From: Ivan T. <to...@cr...> - 2001-08-23 15:14:16
|
On Thu, 2001-08-23 at 16:40, Mahler Thomas wrote:
> > Unfortunately, there isn't quite enough data in the
> > repository.xml file
> > to generate the correct SQL statements. So far, I don't know when to
> > generate 'NOT NULL' and the size of VARCHAR objects.
> >
> > So, perhaps we should add this data to the XML?
> >
>
> Yes I have been thinking in this direction too.
Ok, I've added the following two attributes to jdbc_type: 'not-null' and
'size'. The problem is that (even in the test repository) many tables
are described in several places each, which can lead to inconsitency.
So, what do you think of the following form?
<MappingRepository>
<JdbcConnectionDescriptor id="default">
...
</JdbcConnectionDescriptor>
<JdbcConnectionDescriptor id="other">
...
</JdbcConnectionDescriptor>
...
<TableDescriptor name="table_name" id="tableId"
[jdbc-ref="other"]>
<ColumnDescriptor name="columnName" [primaryKey="yes|no"]
[not-null="yes|no"] .../>
</TableDescriptor>
...
<ClassDescriptor [table-ref="tableId"]>
...
<FieldDescriptor [column-name="columnName"]>
...
</FieldDescriptor>
</ClassDescriptor>
</MappingRepository>
|
|
From: Axel H. <axe...@ar...> - 2001-08-23 14:18:47
|
Hi all, we use OJB for a standalone java-app. In the moment we test it with Microsoft Access. We only use the PersistenceBroker without ODMG or EJB. To get consistency for all parts (repository, interface, proxy class, entity class and ddl to generate) i have expanded the sourcecode of ArgoUml to generate these parts. In the moment it is very rudimentary an exactly programmed for our requests. Unfortunately ArgoUml offers no interfaces to integrate external generators, therefor i have coded the call of my classes directly into the ArgoUml sourcecode. I hope to spend some time next week to complete it. cheers axel |
|
From: Mahler T. <tho...@it...> - 2001-08-23 13:41:13
|
hi all, > -----Urspr=FCngliche Nachricht----- > Von: Ivan Toshkov [mailto:to...@cr...] > Gesendet: Donnerstag, 23. August 2001 15:23 > An: Mahler Thomas > Cc: 'Lasse Lindg=E5rd'; obj...@li... > Betreff: Re: AW: [Objectbridge-developers] generating mapping=20 > files and > databa ses >=20 >=20 > On Thu, 2001-08-23 at 13:08, Mahler Thomas wrote: > > 2. This has already been done by Ivan Toshkov. Just extract=20 > the attached zip > > file into the ojb src directory. > > Now you can use java ojb.broker.metadata repository.xml to=20 > generate the DDL > > !!! > Unfortunately, there isn't quite enough data in the=20 > repository.xml file > to generate the correct SQL statements. So far, I don't know when to > generate 'NOT NULL' and the size of VARCHAR objects. >=20 > So, perhaps we should add this data to the XML? >=20 Yes I have been thinking in this direction too. > (While on the subject, the repository.xml looks somewhat strange, > because of the lack of naming convention. E.g. elements like > FieldDescriptor, field.name and jdbc_type. >=20 > I would personally like to see some of the fields, as attributes. For > example, PrimaryKey could be an attribute to FieldDescriptor. This = can > be used to set a meeningfull default value in the DTD.) >=20 Sure, the DTD is somewhat "homegrown". Any enhancements are = appreciated! > The second issue is with different syntax for the different=20 > DBMSes. IMO, > the best way to do that is to support some kind of pluggable SQL > generators, and I'll try to spend some time on this during the = weekend > (no promises, though :)). >=20 There have already some request in this direction. SO I guess it's good = to have a look at this subject. <thomas/> >=20 > Cheers, > Ivan >=20 |
|
From: Ivan T. <to...@cr...> - 2001-08-23 13:23:25
|
On Thu, 2001-08-23 at 13:08, Mahler Thomas wrote: > 2. This has already been done by Ivan Toshkov. Just extract the attached zip > file into the ojb src directory. > Now you can use java ojb.broker.metadata repository.xml to generate the DDL > !!! Unfortunately, there isn't quite enough data in the repository.xml file to generate the correct SQL statements. So far, I don't know when to generate 'NOT NULL' and the size of VARCHAR objects. So, perhaps we should add this data to the XML? (While on the subject, the repository.xml looks somewhat strange, because of the lack of naming convention. E.g. elements like FieldDescriptor, field.name and jdbc_type. I would personally like to see some of the fields, as attributes. For example, PrimaryKey could be an attribute to FieldDescriptor. This can be used to set a meeningfull default value in the DTD.) The second issue is with different syntax for the different DBMSes. IMO, the best way to do that is to support some kind of pluggable SQL generators, and I'll try to spend some time on this during the weekend (no promises, though :)). Cheers, Ivan |
9 messages has been excluded from this view by a project administrator.
