objectbridge-jdo-dev Mailing List for ObJectRelationalBridge (Page 4)
Brought to you by:
thma
Menu
▾
▴
objectbridge-jdo-dev — OJB JDO developer list
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(32) |
Feb
(2) |
Mar
(13) |
Apr
(25) |
May
(104) |
Jun
(23) |
Jul
(11) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <tr...@th...> - 2002-05-26 00:15:56
|
Thomas, with regards to extension naming, i'm thinking that using the ojb repository naming conventions like table vs. table-name won't really match, because you also have column.name and jdbc_type which seems a little inconsistent. So for consistency's sake, I propose the new names like so: <extension vendor-name="ojb" table-name="Product"/> <extension vendor-name="ojb" column-name="stock" jdbc-type="INTEGER"/> It's more descriptive and matches the jdo naming conventions. Travis |
|
From: <tr...@th...> - 2002-05-26 00:10:35
|
I think the new jdo.jar you uploaded is invalid? I get unexpected end of archive when trying to open it and i can't run the tutorial anymore. Anyone else having this problem? Travis |
|
From: Brian W. <bw...@mc...> - 2002-05-25 14:47:02
|
Hi ojb developers, It=92s great to learn of your efforts to write an open-source JDO product= ! Having used the free JDO stuff bundled with Forte for Java 3.0, I=92m smi= tten by the benefits of JDO, but since JDO is discontinued in the next release= of Forte (now called Sun ONE), I=92m looking for a replacement. I can=92t he= lp out much with ojb right now, as I=92m knee deep in a couple projects until at least mid-Summer. So if you don=92t mind I=92ll mostly just keep reading = the dev mailing list. Having said this=85=85, I do have one possible small (code) contribution.= As you consider default mappings, you might consider using the conventions used = by the schema reverse engineering tool bundled with Forte for Java (which generates classes from an existing schema). This converts database schema using underscores for word separators (e.g. MY_TABLE, MY_COLUMN) into Java-like mixed case names (e.g. MyClass, myProperty). This convention allows one to quickly set up JDO objects to talk with an existing databas= e schema without any underscores in Java class names. If ojb used this convention, ojb users with existing databases could use the Forte tool to generate initial versions of their classes. I know such a simple mapping (table to class, column to property) is simplistic, etc., but it sure is = a great way to get started. Another option, if you=92re not comfortable wit= h this particular convention, is to add an extension tag to the *.jdo file (perhaps at the package and/or class level) indicating that this conventi= on was in use. If you=92d like, I=92d be delighted to contribute code and JU= nit tests to the project that do these conversions. I look forward to seeing your thoughts on the list related to this idea o= n default mappings. Keep the faith! -- Brian Brian Westrich McWest Corp. bw...@mc... 612-508-1827 |
|
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 > > > > |
|
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: <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: <tr...@th...> - 2002-05-24 20:25:59
|
> If so we can easily kickout the JDORI enhancer and plugin JADOE! Gladly! Can't wait to see it. Travis |
|
From: Thomas M. <tho...@ho...> - 2002-05-24 20:00:45
|
Hi Andy, Andy Lewis wrote: > The key point about the JDO file is that it is specified by the standard. Right, but JDO does not require us to *rely* on a JDO file. It would be 100% JDO compliant to simply generate a plain *.jdo file without any vendor extensions and to keep the O/R mapping info in a separate place. (As I suggested originally). > If they didn't specify it, that would be different.... If JDO specified how to keep O/R info in a *.jdo file this discussion wouldn't have occured... cheers, Thomas > > >>Hi Christian, >> >>Christian Sell wrote: >> >><snip> >> >>>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 absolutely agree with you! >> >>That's why I was so sceptic about the *.JDO idea. >> >>That's why I said: the OJB DescriptorRepository must be the guide line! >>But if we can have all necessary information in a *.jdo file I see no >>problems in generating the DescriptorRepository from it. >> >>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 >> > > > "The heights of genius are only measurable by the depths of stupidity." > > > > _______________________________________________________________ > > 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 19:47:29
|
The key point about the JDO file is that it is specified by the standard. If they didn't specify it, that would be different.... > Hi Christian, > > Christian Sell wrote: > > <snip> >> >> 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 absolutely agree with you! > > That's why I was so sceptic about the *.JDO idea. > > That's why I said: the OJB DescriptorRepository must be the guide line! > But if we can have all necessary information in a *.jdo file I see no > problems in generating the DescriptorRepository from it. > > 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 "The heights of genius are only measurable by the depths of stupidity." |
|
From: Thomas M. <tho...@ho...> - 2002-05-24 19:39:55
|
Hi Christian, Christian Sell wrote: <snip> > > 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 absolutely agree with you! That's why I was so sceptic about the *.JDO idea. That's why I said: the OJB DescriptorRepository must be the guide line! But if we can have all necessary information in a *.jdo file I see no problems in generating the DescriptorRepository from it. cheers, Thomas |
|
From: Thomas M. <tho...@ho...> - 2002-05-24 19:31:54
|
Hi Mika, Mika Riekkinen wrote: > Hi Thomas! > I just read OJB plans about supporting JDO with OJB > 2.0. In fact we already have a working JDO prototype implementation ! > We are currently implementing JDO Enhancer as an open > source project in sourceforge. It's in an very early > stage, but we are confident about the implementation. > great news! > You may wish to take a look at it: > http://sourceforge.net/projects/jadoe/ > > We have not set up any project home page or anything. > Basically, what Jadoe does, is to make the enhancer > part of the JDO specification. Currently we are > implemeting this with bytecode manipulation. > PersistenceCapable classes are created on the fly, as > opposed to some precompiler. cool. > > We are going to support pre-compiled > PersistenceCapable classes as well. The choice is left > to user. Or JDO implementation. > > Bytecode manipulation is done using Jiapi: > http://sourceforge.net/projects/jiapi/ > > Jiapi provides high level bytecode manipulation > capabilities. > just curious: why do you use Jiapi instead of the defact-standard BCEL? > > The status of jadoe is at alpha level. We have been > succesfully been able to generate all the needed > interfaces and methods. Some of the needed fields are > allready generated, so we are almost there. > There are some problems relating mostly to Jiapi, so > we cannot finalize this Jadoe part. We will first fix > these Jiapi related problems, and then it will take > only a couple of weeks to finalize Jadoe. > Mabe you should have a look at BCEL (to be found at JAKARTA)? > We are looking for an opensource JDO implementation, > so that we can plug Jadoe into it. ObjectBridge would > be an ideal candidate for it. > I agree. In our current JDO prototype we are using the enhancer from the JDORI. We would be happy to replace this with an opensource solution ASAP! > I read your mailing lists, and someone pointed > correctly out, that these two entities can be > developed individually from each other. ACK! > If you think, that Jadoe would suit your needs for the > Reference Enhancer, we are happy to merge our codebase > to yours. As OJB will move to Jakarta soon (we have been as a Jakarta Toplevel subproject) there would be a lot of interest for your tool! > Or if you would prefer a more pluggable RE > scheme, we can help you defining these Reference > Enhancer plugin mechanisms. > We will need further discussions if there are special enhancement requirements for OJB. I'm not sure about it yet! What exactly is your enhancer doing? is it generating the same things as the JDORI enhancer? If so we can easily kickout the JDORI enhancer and plugin JADOE! cheers, Thomas Mika: |
|
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: Andy L. <aj...@as...> - 2002-05-24 18:14:08
|
missed the list...sorry.... > THe spec allows jdo files a several levels - system, package, etc. > > As far as the connection info, I would limit the info contained in the > jdo file to a symbolic reference to the conenction, and allow the > connection to be specified elsewhere - respository.xml or some other > item that can be loaded from the class path, or even programmatically. > Keep in mind that some people are going to want to package all the JDO > stuff in a > JAR/WAR/EAR, and it may not be convienent to modify resource entires > within that archive at deployment time. > >> 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 >> > >> >> > >> > >> > >> > >> >> >> >> _______________________________________________________________ >> >> 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 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 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: Christian S. <nc-...@ne...> - 2002-05-24 17:29:47
|
---- 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 |
|
From: Thomas M. <tho...@ho...> - 2002-05-24 17:23:55
|
Hi Sebasthian, Sebastian Kanthak wrote: <snip> > I've already inspected Travis's implementation carefully and crawled through > the ojb sources (especially the odmg and the broker part) a bit and read your > proposal. However, as I tried to explain in my earlier thread with Travis > last week, I don't think, that a compliant JDO implementation is possible > that way. > I agree, a *lot* of things are missing: (Transaction management, Instance Lifecycle Management, Dirty detection, partial loading, JDOQL, etc.) This will require a lot more thinking, no doubt! > As all communication with the persistence capable instance should be done via > the StateManager, we probably would require a new PersistentField > implementation. ACK > As far as I see, objects are created by RowReaders. The > DefaultRowReaderImpl uses either a multi-arg constructor or reflection to > create new objects. We would probably need another implementation, because > JDO objects should be created via JDOImplHelper and one needs a StateManager > for the new instance. > ACK > Another point is about lazy-materialization. Currently, this is done via > Proxy objects. However, this can be done better in JDO (not requiring an > interface type anymore) with help of the StateManager. ACK > I'm not sure, where > this stuff is located, so I don't have an idea, what changes would be > necessary. For ojb.broker.metadata.PersistentField and for ojb.broker.accesslayer.RowReader you just have to code a new (JDO compliant) Implementation and you have to tell OJB to use these implementations in OJB.properties in the respective entries. The StateManager stuff will be one of the most interesting (and difficult) things. But implementing a lazy load mechanizm without OJB proxies will be quite simple: ReferenceDescriptors and CollectionDescriptor will be declared as *not* using proxies and as *not* using automatic load (this would be declared in the repository.jdo file). WIth these simple settings OJB won't load references and collection attributes. So the StateManager can implement its own logic for loading references and collections. (Of course it can again use the PersistenceBroker and Query Objects to load those attributes.) > > Probably there are easier solutions than I have suggested, because I don't > know the ojb source well enough. > I think you found the right "hooks"! > Another point is JDO's notion of a "default fetch group". The idea is, to > load all fields in this group together, and other fields on-demand. I think, > ojb loads everything belonging to one object at once. As this is not require > by the spec, it would be ok, but one could think about, if this > default-fetch-group would give us a better performance in some situations. > This is also possible with OJB: OJB does load only those attributes defined in an Objects ClassDescriptor. It is very easy to modify ClassDecsriptors at runtime to fill only specific attributes! > >>fine, all help is appreciated. >> > > As you've probably noticed, I've already started thinking, how to use ojb for > a jdo implementation, but are still in the state of analyzing, how ojb > exactly works and where the best points to start form are. No problem! OJB has grown quite big (> 450 classes) and it takes some time to get familiar with it. ciao, Thomas |
|
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: Andy L. <aj...@as...> - 2002-05-24 17:08:42
|
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. > 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 "The heights of genius are only measurable by the depths of stupidity." |
|
From: Thomas M. <tho...@ho...> - 2002-05-24 16:57:44
|
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: <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: Sebastian K. <seb...@mu...> - 2002-05-23 18:01:33
|
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... |
|
From: Sebastian K. <seb...@mu...> - 2002-05-23 18:01:33
|
Hi Thomas, On Thursday 23 May 2002 09:52, Mahler Thomas wrote: > If you have a short look at Travis' implementation you will see that it > does not make use of any internal OJB structures. It is a simple > PersistenceBroker API client application. > > The same holds true for the OJB-ODMG implementation: it is just a client > using the PersistenceBroker Interface. > > I explained this layered approch in my jdo-psoposal: > http://objectbridge.sourceforge.net/jdo/jdo-proposal.html I've already inspected Travis's implementation carefully and crawled through the ojb sources (especially the odmg and the broker part) a bit and read your proposal. However, as I tried to explain in my earlier thread with Travis last week, I don't think, that a compliant JDO implementation is possible that way. As all communication with the persistence capable instance should be done via the StateManager, we probably would require a new PersistentField implementation. As far as I see, objects are created by RowReaders. The DefaultRowReaderImpl uses either a multi-arg constructor or reflection to create new objects. We would probably need another implementation, because JDO objects should be created via JDOImplHelper and one needs a StateManager for the new instance. Another point is about lazy-materialization. Currently, this is done via Proxy objects. However, this can be done better in JDO (not requiring an interface type anymore) with help of the StateManager. I'm not sure, where this stuff is located, so I don't have an idea, what changes would be necessary. Probably there are easier solutions than I have suggested, because I don't know the ojb source well enough. Another point is JDO's notion of a "default fetch group". The idea is, to load all fields in this group together, and other fields on-demand. I think, ojb loads everything belonging to one object at once. As this is not require by the spec, it would be ok, but one could think about, if this default-fetch-group would give us a better performance in some situations. > fine, all help is appreciated. As you've probably noticed, I've already started thinking, how to use ojb for a jdo implementation, but are still in the state of analyzing, how ojb exactly works and where the best points to start form are. Perhaps some ojb developer can give me some hints on the points mentioned above. ciao Sebastian -- Sebastian Kanthak | seb...@mu... |
|
From: Andy L. <aj...@as...> - 2002-05-23 16:19:32
|
I'm strongly of the opinion that we should rely on the JDO file, and use the vendor extenions. > Well the extenstion tag is part of the jdo spec and is for vendor > specific information. > > 18.5 ELEMENT extension > This element specifies JDO vendor extensions. The vendor-name attribute > is required. The vendor name "JDORI" is reserved for use by the JDO > reference implementation. The key and value attributes are optional, > and have vendor-specific meanings. They may be ignored by any JDO > implementation. > > So my thoughts are that people that want to use JDO, can use the jdo > file, and the JDO implementation can just setup the ojb metadata > classes using the jdo information. This would be in place of > repository_user.xml, probably not the repository.xml that holds the > database information. > > Travis > > ---- Original Message ---- > From: Mahler Thomas <tho...@it...> > Sent: 2002-05-23 > To: "'tr...@th...'" <tr...@th...>, > obj...@so... > Subject: AW: [Objectbridge-jdo-dev] jdo extension > > Hi Travis, > > I don't think that its a good idea to replace the repository.xml by a > .jdo file. > The JDO spec does not provide any O/R specifics like foreign-keys or > jdbc-types. > But these information are needed by OJB! > > My suggestion: > The OJB DescriptorRepository (populated from the repository.xml) does > contain *all* OJB meta-data. > We currently use this repository for all OJB runtime metadata > operations and also for generation of DDL, Java code for persistent > class and also for generation of repository.xml files. > > 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) > > cheers, > > Thomas > >> >> >> Just thinking of how to do table mapping in the jdo files and >> here's my thoughts from sample app: >> >> <jdo> >> <package name="test.ojb.tutorial3a"> >> <class name="Product" identity-type="application"> >> <extension vendor-name="ojb" table-name="Product"/> >> <field name="id" primary-key="true"> >> <extension vendor-name="ojb" column-name="id"/> >> </field> >> <field name="name"> >> <extension vendor-name="ojb" column-name="name"/> >> </field> >> <field name="price"> >> <extension vendor-name="ojb" column-name="price"/> >> </field> >> <field name="stock"> >> <extension vendor-name="ojb" column-name="stock"/> >> </field> >> </class> >> </package> >> </jdo> >> >> >> I don't think we'll need the jdbc datatypes anymore do we? feedback? >> >> 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 >> > > > > _______________________________________________________________ > > 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." |
