Thread: RE: Re: AW: [Objectbridge-jdo-dev] jdo extension
Brought to you by:
thma
Menu
▾
▴
objectbridge-jdo-dev
|
From: <tr...@th...> - 2002-05-23 18:06:05
|
+1 I think the jdo file should encompass all that is needed as well. travis ---- Original Message ---- From: Sebastian Kanthak <seb...@mu...> Sent: 2002-05-23 To: obj...@so... Subject: Re: AW: [Objectbridge-jdo-dev] jdo extension Hi, On Thursday 23 May 2002 10:49, Mahler Thomas wrote: > If we need a *.jdo file to be JDO compliant we should generate it from the > OJB DescriptorRepository! > This is rather simple, fits to the existiting OJB metadata architecture and > it will allow to write 100% spec conformant *.jdo files (as they won't need > to contain vendor specifics) well, a spec conformant jdo-file may contain vendor-extensions, this is covered by the spec. Of course, the semantics of these extensions isn't specified. A jdo file is required by the jdo-spec and it must contain all persistent-capable classes at least. It can, however, contain as many vendor-extensions as you want. I think it would be a greate feature, if such a simple jdo file (without any ojb extensions) would be sufficient to run ojb-jdo. This would make it much easier to change from any jdo-implementation to ojb and vice-versa. Table and column names could be filled with default values, if nothing is specified. Of course, one can override this in a way similar to what Travis proposed, if one has to match an existing schema. So my suggestion would be to generate all meta-data out of the jdo-file, using default values where something isn't specified via an extension. Of course, this has something to do with your point of view: Do you want to use ojb and see jdo as a nice feature, or do you want to use jdo and see ojb as one (of many other) implementations... Perhaps, both approachs could be supported. ciao Sebastian -- Sebastian Kanthak | seb...@mu... _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm _______________________________________________ Objectbridge-jdo-dev mailing list Obj...@li... https://lists.sourceforge.net/lists/listinfo/objectbridge-jdo-dev |
|
From: <tr...@th...> - 2002-05-24 17:13:14
|
Problem... The jdo files are on a package by package basis, so you may have one jdo file per package, but what if you are using multiple packages, then having the database connection information is redundant and "bad". ;-) So maybe we still need the repository.xml just for the database info? I am working on the other parts of it as we speak, but this part through me for a loop. Travis PS. Thomas, can you change the reply to on these lists to go to the list? ---- Original Message ---- From: Thomas Mahler <tho...@ho...> Sent: 2002-05-24 To: Sebastian Kanthak <seb...@mu...> Subject: Re: AW: [Objectbridge-jdo-dev] jdo extension Hi Sebastian, Sebastian Kanthak wrote: > Hi, > > On Thursday 23 May 2002 10:49, Mahler Thomas wrote: > >>If we need a *.jdo file to be JDO compliant we should generate it from the >>OJB DescriptorRepository! >>This is rather simple, fits to the existiting OJB metadata architecture and >>it will allow to write 100% spec conformant *.jdo files (as they won't need >>to contain vendor specifics) >> > > well, a spec conformant jdo-file may contain vendor-extensions, this is > covered by the spec. Of course, the semantics of these extensions isn't > specified. > ACK > A jdo file is required by the jdo-spec and it must contain all > persistent-capable classes at least. It can, however, contain as many > vendor-extensions as you want. > ACK > I think it would be a greate feature, if such a simple jdo file (without any > ojb extensions) would be sufficient to run ojb-jdo. Mhh. This would be great, but without extensions we won't be able to specify a foreign-key relation between two tables. We even won't be able to specify on what table a given class is mapped. So this approach would work only for the most simple cases, where OJB can choose some common-sense defaults for table-names, etc. > This would make it much > easier to change from any jdo-implementation to ojb and vice-versa. Table and > column names could be filled with default values, if nothing is specified. Of > course, one can override this in a way similar to what Travis proposed, if > one has to match an existing schema. > > So my suggestion would be to generate all meta-data out of the jdo-file, > using default values where something isn't specified via an extension. > This would be possible. The OJB RepositoryPersistor could be extended to build up the OJB DescriptoRepository from the JDO file. This should quite straightforward to implement. In order to make this approach solid we will need vendor extensions to allow to have *all* meta-information required for OJB in the *.jdo file. I suggest to use syntax element from the latest OJB repository DTD (see attached file). This new DTD defines the syntax for the OJB 1.0 repository.xml. I hope there won't be too many changes on it till final relase. > Of course, this has something to do with your point of view: Do you want to > use ojb and see jdo as a nice feature, or do you want to use jdo and see ojb > as one (of many other) implementations... > > Perhaps, both approachs could be supported. > I got your point! This is really a good argument to use a .jdo file covering *all* necessary information. I now agree, that we should do it this way! cheers, Thomas |
|
From: Thomas M. <tho...@ho...> - 2002-05-24 17:34:31
|
Hi Travis, tr...@th... wrote: > Problem... > > The jdo files are on a package by package basis, so you may have one > jdo file per package, but what if you are using multiple packages, > then having the database connection information is redundant and > "bad". ;-) > But it would be 100% JDO compliant ;-) > So maybe we still need the repository.xml just for the database > info? Mhh. WOuld be possible. But I I think this would be even more confusing for the user than using a repository.xml exclusively! > I am working on the other parts of it as we speak, but this > part through me for a loop. > > Travis > > PS. Thomas, can you change the reply to on these lists to go to the > list? > I fear its the default setting for the SourceForge mailinglists. A lot of people have complaint about it, but SF tells you that they want you to press "reply all" !!! cheers, Thomas > ---- Original Message ---- From: Thomas Mahler > <tho...@ho...> Sent: 2002-05-24 To: Sebastian Kanthak > <seb...@mu...> Subject: Re: AW: > [Objectbridge-jdo-dev] jdo extension > > Hi Sebastian, > > Sebastian Kanthak wrote: > > >> Hi, >> >> On Thursday 23 May 2002 10:49, Mahler Thomas wrote: >> >> >>> If we need a *.jdo file to be JDO compliant we should generate >>> it from the OJB DescriptorRepository! This is rather simple, >>> fits to the existiting OJB metadata architecture and it will >>> allow to write 100% spec conformant *.jdo files (as they won't >>> need to contain vendor specifics) >>> >>> >> well, a spec conformant jdo-file may contain vendor-extensions, >> this is covered by the spec. Of course, the semantics of these >> extensions isn't specified. >> >> > > ACK > > > >> A jdo file is required by the jdo-spec and it must contain all persistent-capable >> classes at least. It can, however, contain as many vendor-extensions >> as you want. >> >> > > > ACK > > > >> I think it would be a greate feature, if such a simple jdo file >> (without any ojb extensions) would be sufficient to run ojb-jdo. >> > > > Mhh. This would be great, but without extensions we won't be able to specify a foreign-key relation between two tables. We even won't be able > to specify on what table a given class is mapped. > > So this approach would work only for the most simple cases, where OJB > can choose some common-sense defaults for table-names, etc. > > >>This would make it much >>easier to change from any jdo-implementation to ojb and vice-versa. Table and >>column names could be filled with default values, if nothing is specified. Of >>course, one can override this in a way similar to what Travis proposed, if >>one has to match an existing schema. >> >> > >>So my suggestion would be to generate all meta-data out of the jdo-file, >>using default values where something isn't specified via an extension. >> >> > > > This would be possible. The OJB RepositoryPersistor could be extended to > build up the OJB DescriptoRepository from the JDO file. This should > quite straightforward to implement. > > In order to make this approach solid we will need vendor extensions to > allow to have *all* meta-information required for OJB in the *.jdo file. > I suggest to use syntax element from the latest OJB repository DTD (see > attached file). This new DTD defines the syntax for the OJB 1.0 > repository.xml. I hope there won't be too many changes on it till final > relase. > > > >>Of course, this has something to do with your point of view: Do you want to >>use ojb and see jdo as a nice feature, or do you want to use jdo and see ojb >>as one (of many other) implementations... >> >>Perhaps, both approachs could be supported. >> >> > > > I got your point! This is really a good argument to use a .jdo file > covering *all* necessary information. > > I now agree, that we should do it this way! > > cheers, > > Thomas > > > > > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > _______________________________________________ > Objectbridge-jdo-dev mailing list > Obj...@li... > https://lists.sourceforge.net/lists/listinfo/objectbridge-jdo-dev > > > > > > specify a foreign-key relation between two tables. We even won't > be able to specify on what table a given class is mapped. > > So this approach would work only for the most simple cases, where > OJB can choose some common-sense defaults for table-names, etc. > > >> This would make it much easier to change from any >> jdo-implementation to ojb and vice-versa. Table and column names >> could be filled with default values, if nothing is specified. Of course, one can override this in a way similar to what Travis proposed, if >>one has to match an existing schema. >> >> > >>So my suggestion would be to generate all meta-data out of the jdo-file, >>using default values where something isn't specified via an extension. >> >> > > > This would be possible. The OJB RepositoryPersistor could be extended to > build up the OJB DescriptoRepository from the JDO file. This should > quite straightforward to implement. > > In order to make this approach solid we will need vendor extensions to > allow to have *all* meta-information required for OJB in the *.jdo file. > I suggest to use syntax element from the latest OJB repository DTD (see > attached file). This new DTD defines the syntax for the OJB 1.0 > repository.xml. I hope there won't be too many changes on it till final > relase. > > > >>Of course, this has something to do with your point of view: Do you want to >>use ojb and see jdo as a nice feature, or do you want to use jdo and see ojb >>as one (of many other) implementations... >> >>Perhaps, both approachs could be supported. >> >> > > > I got your point! This is really a good argument to use a .jdo file > covering *all* necessary information. > > I now agree, that we should do it this way! > > cheers, > > Thomas > > > > > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > _______________________________________________ > Objectbridge-jdo-dev mailing list > Obj...@li... > https://lists.sourceforge.net/lists/listinfo/objectbridge-jdo-dev > > > > >> >>course, one can override this in a way similar to what Travis >> proposed, if one has to match an existing schema. >> >> > >> So my suggestion would be to generate all meta-data out of the >> jdo-file, using default values where something isn't specified >> via an extension. >> >> > > > This would be possible. The OJB RepositoryPersistor could be > extended to build up the OJB DescriptoRepository from the JDO > file. This should quite straightforward to implement. > > In order to make this approach solid we will need vendor extensions > to allow to have *all* meta-information required for OJB in the > *.jdo file. I suggest to use syntax element from the latest OJB > repository DTD (see attached file). This new DTD defines the > syntax for the OJB 1.0 repository.xml. I hope there won't be too > many changes on it till final relase. > > > >> Of course, this has something to do with your point of view: Do >> you want to use ojb and see jdo as a nice feature, or do you >> want to use jdo and see ojb as one (of many other) >> implementations... >> >> Perhaps, both approachs could be supported. >> >> > > > I got your point! This is really a good argument to use a .jdo file covering > *all* necessary information. > > I now agree, that we should do it this way! > > cheers, > > Thomas > > > > > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference August > 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > _______________________________________________ Objectbridge-jdo-dev > mailing list Obj...@li... https://lists.sourceforge.net/lists/listinfo/objectbridge-jdo-dev > > > > > |
|
From: <tr...@th...> - 2002-05-24 17:45:00
|
How does this sound for starters anyways: JDO Extensions Set the referenced table using table-name as an extension of the class. <class name="Product" identity-type="application"> <extension vendor-name="ojb" table-name="Product"/> Set the referenced column in the above table using column-name and optionally a jdbc-type. jdbc-type matches the ojb type mapping. <field name="stock"> <extension vendor-name="ojb" column-name="stock" jdbc-type="INTEGER"/> </field> If no extensions are specified then the following default mappings will occur: table-name=Class.getName() column-name=field name jdbc-type=equivalent java type Travis ---- Original Message ---- From: Christian Sell <nc-...@ne...> Sent: 2002-05-24 To: obj...@so... Subject: Re: AW: [Objectbridge-jdo-dev] jdo extension ---- Original message ---- >Having enough defaults so that a pure stnadard .jdo file will handle the >most obvious cases is a huge step forward in usability, ease of use, and >reducing learning curve. > >I think htis should be a major objective actually. Not only does it make it >easier to work with, but I have found that easeo of use ascpects like this >tend to force cleaner architectures as well. > I disagree. A database is a resource that must not be taken lightly, as it has the strongest performance implications if treated wrongly. Luring people into the illusion that they can do away with it by the push of a button has the potential of generating disappointments. IMO, a good O/R framework must either exploit or allow easy access to the full capabilities of the underlying DBMS. And in a corporate production scenario, you will almost always have to map your objects to a pre-existing schema. I see a value in generating default mappings as a starting point for projects that have the privilege of starting from scratch, however. regards, Christian _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm _______________________________________________ Objectbridge-jdo-dev mailing list Obj...@li... https://lists.sourceforge.net/lists/listinfo/objectbridge-jdo-dev |
|
From: Thomas M. <tho...@ho...> - 2002-05-24 19:51:00
|
Hi Travis, tr...@th... wrote: > How does this sound for starters anyways: > > JDO Extensions > > Set the referenced table using table-name as an extension of the class. > > <class name="Product" identity-type="application"> > <extension vendor-name="ojb" table-name="Product"/> > > Set the referenced column in the above table using column-name and optionally a jdbc-type. jdbc-type matches the ojb type mapping. > > <field name="stock"> > <extension vendor-name="ojb" column-name="stock" jdbc-type="INTEGER"/> > </field> > ACK! But I think its better to use the same syntax as in the (1.0) repository.dtd: <class name="Product" identity-type="application"> <extension vendor-name="ojb" table="Product" /> <field name="stock"> <extension vendor-name="ojb" column="stock" jdbc-type="INTEGER"/> </field> This will make it much easier to see which *.jdo attribute matches to a repository.xml attribute. > If no extensions are specified then the following default mappings will occur: > > table-name=Class.getName() > > column-name=field name > > jdbc-type=equivalent java type > > ACK! What about primary keys and foreign keys for references and collections? Any ideas about default naming conventions? cheers, Thomas |
|
From: Andy L. <aj...@as...> - 2002-05-24 18:14:32
|
and missed again.... > I think that works. > >> How does this sound for starters anyways: >> >> JDO Extensions >> >> Set the referenced table using table-name as an extension of the >> class. >> >> <class name="Product" identity-type="application"> >> <extension vendor-name="ojb" table-name="Product"/> >> >> Set the referenced column in the above table using column-name and >> optionally a jdbc-type. jdbc-type matches the ojb type mapping. >> >> <field name="stock"> >> <extension vendor-name="ojb" column-name="stock" jdbc-type="INTEGER"/> >> </field> >> >> If no extensions are specified then the following default mappings >> will occur: >> >> table-name=Class.getName() >> >> column-name=field name >> >> jdbc-type=equivalent java type >> >> >> >> Travis >> >> ---- Original Message ---- >> From: Christian Sell <nc-...@ne...> >> Sent: 2002-05-24 >> To: obj...@so... >> Subject: Re: AW: [Objectbridge-jdo-dev] jdo extension >> >> >> >> ---- Original message ---- >>>Having enough defaults so that a pure stnadard .jdo file >> will handle the >>>most obvious cases is a huge step forward in usability, ease >> of use, and >>>reducing learning curve. >>> >>>I think htis should be a major objective actually. Not only >> does it make it >>>easier to work with, but I have found that easeo of use >> ascpects like this >>>tend to force cleaner architectures as well. >>> >> >> I disagree. A database is a resource that must not be taken >> lightly, as it has the strongest performance implications if >> treated wrongly. Luring people into the illusion that they >> can do away with it by the push of a button has the potential >> of generating disappointments. >> IMO, a good O/R framework must either exploit or allow easy >> access to the full capabilities of the underlying DBMS. And >> in a corporate production scenario, you will almost always >> have to map your objects to a pre-existing schema. >> >> I see a value in generating default mappings as a starting >> point for projects that have the privilege of starting from >> scratch, however. >> >> regards, >> Christian > > I agree it should not be taken lightly. However anytime the tools can > make a reasonable asumption, it should. That should in no way limit the > ability to manually adjust and set every existing option for tuning or > specific usages. > > The problem with generating default mapping and then cusomtizing them > by hand is that it does not provide a good maintenenance cycle when the > model changes. Do you regenerate, and recusomtize? Or make all the > changes manually? > > A mapping specification that only includes overrides to known defaults > on the other hand allows you to only deal with new or changes variances > from the defaults. I am also a fan of tools to go between object model, > mapping file, and database, and being able to starting with any of the > three and produce at least a starting point for either of the other > two. > > >> >> _______________________________________________________________ >> >> Don't miss the 2002 Sprint PCS Application Developer's Conference >> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm >> >> _______________________________________________ >> Objectbridge-jdo-dev mailing list >> Obj...@li... >> https://lists.sourceforge.net/lists/listinfo/objectbridge-jdo-dev >> >> >> >> _______________________________________________________________ >> >> Don't miss the 2002 Sprint PCS Application Developer's Conference >> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm >> >> _______________________________________________ >> Objectbridge-jdo-dev mailing list >> Obj...@li... >> https://lists.sourceforge.net/lists/listinfo/objectbridge-jdo-dev > > > "The heights of genius are only measurable by the depths of stupidity." "The heights of genius are only measurable by the depths of stupidity." |
|
From: <tr...@th...> - 2002-05-24 20:47:35
|
>But I think its better to use the same syntax as in the (1.0) > repository.dtd: Fine by me as long as everyone is in agreement. > What about primary keys and foreign keys for references and collections? Collections, already handled in the spec, excerpt below: 18.4.1 ELEMENT collection This element specifies the element type of collection typed fields. The default is Collection typed fields are persistent, and the element type is Object. The element-type attribute specifies the type of the elements. The embedded-element attribute specifies whether the values of the elements should be stored if possible as part of the instance instead of as their own instances in the datastore. It defaults to "false" for persistence-capable types and interface types; and "true" for other types. Java Data Objects1.0 18.4.2 ELEMENT map This element specifies the treatment of keys and values of map typed fields. The default is map typed fields are persistent, and the key and value types are Object. The key-type and value-type attributes specify the types of the key and value, respectively. The embedded- key and embedded-value attributes specify whether the key and value should be stored if possible as part of the instance instead of as their own instances in the datastore. They default to "false" for persistence-capable types and interface types; and "true" for other types. 18.4.3 ELEMENT array This element specifies the element type of array typed fields. The default is array typed fields are persistent, according to the rules above. The embedded-element attribute specifies whether the values of the elements should be stored if possible as part of the instance instead of as their own instances in the datastore. It defaults to "false" for persistence- capable element types and interface types; and "true" for other types. > Any ideas about default naming conventions? Do you mean default name mapping from java field to table column? If so, I would say identical to the java field name. ex: quantity -> quantity productGroup -> productGroup Same for class names to tables. travis |
|
From: Sebastian K. <seb...@mu...> - 2002-05-24 21:18:44
|
Hi Travis, On Friday 24 May 2002 22:41, tr...@th... wrote: > > Any ideas about default naming conventions? > > Do you mean default name mapping from java field to table column? If so, I > would say identical to the java field name. > > ex: > quantity -> quantity > productGroup -> productGroup I think there are some issues with most databases. First of all, there certainly are reserved keywords like SELECT, FROM, WHERE and so on, but nobody can forbid you to name your java fields likes this. So we would need some conversion (like appending something) here. Another problem is, that most databases have a maximum length for names, ignoring everything after the n-th character. This could result in different names being cut of ending up the same. So we should cut up, say, at n-2 and add an increasing number. Same problem for classes in different packages. There was an interesting thread on www.jdocentral.com a few weeks ago. However, this certainly isn't that important. We could use the simple-conversion as long as we introduce some hooks to add the advanced functionality later. ciao Sebastian -- Sebastian Kanthak | seb...@mu... Q: What do agnostic, insomniac dyslexics do at night? A: Stay awake and wonder if there's a dog. |
|
From: Thomas M. <tho...@ho...> - 2002-05-24 21:59:37
|
Hi again, tr...@th... wrote: <snip> > >>Any ideas about default naming conventions? >> > > Do you mean default name mapping from java field to table column? If so, I would say identical to the java field name. > > ex: > quantity -> quantity > productGroup -> productGroup > > Same for class names to tables. ACK. But what about the primary key attributes, foreign key attributes etc. For marking primary key fields we can use the "primary-key" attribute of the <field>-element. So far But for building ReferenceDescriptors and CollectionDescriptors OJB must know which fields of a persistent class serve as foreign key for the reference or collection field. if a ProductGroup (with primary key field "id") has a Vector of Articles in an attribute "allArticles", each Article needs a field "fkProductGroup" that contains the foreign key pointing to the primary key "id" of ProductGroup. You'll need default namings for those things too, otherwise OJB load and store references and collections! cheers, Thomas > > travis > > > > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > _______________________________________________ > Objectbridge-jdo-dev mailing list > Obj...@li... > https://lists.sourceforge.net/lists/listinfo/objectbridge-jdo-dev > > > > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X