Hi Daniel, some more thoughts: IMO it is important to get a clear picture of your requirements. 1. Do want a transparent persistent store. (and storing data in RDBMS is not manadtory)or 2. Do want an automated object/relational mapping? (because storing in a RDBMS is manadatory)
I've got the impression that you are looking for 1. ? For a completely transparent storage there are better tools available than O/R tools! OODBMS do a very good job at this. There are very clever derivates of the OODBMS approach available, e.g. Prevayler.(http://www.prevayler.org/). If keeping data in an RDBMS is *not* mandatory you won't need more. But if you have to use an RDBMS as backend store things are more complicated. AFAIK The only product that can do this is POET. They build this feature because they had clients who did not want to store application data in an OODBMS backend but wanted to have everything in an RDBMS. AFAIK this branch of the POET productline was not a big success. - it's easy to reverse engineer existing database tables to a repository.xml and/or java classes. - it's easy to generate database tables and persistent classes from an existing repository.xml. - But it's definitely not possible to generate repository.xml from java classes without having additional meta information (I gave some examples in my original reply). Maybe it's possible to do simple things without additional information by making some default assumptions. But not a 100% solution. The idea to have joined efforts for such a forward engineering tool is inviting. But I'm in doubt if such a thing is going to happen. Some time ago the OJB team proposed to have a common performance testsuite that could be used by all opensource O/R tools. We offered to use our existing performance testsuite as a starting point. We invited other teams and never got a reply... cheers, Thomas > -----Original Message----- > From: Daniel Shriver [mailto:[EMAIL PROTECTED]] > Sent: Friday, February 21, 2003 12:52 AM > To: 'OJB Users List' > Subject: RE: automatic generation of XML mapping files from Java > codebase > > > -----Original Message----- > From: David Jencks [mailto:[EMAIL PROTECTED]] > Sent: Thursday, February 20, 2003 5:52 PM > To: OJB Users List > Subject: RE: automatic generation of XML mapping files from Java > codebase > > > Personally I think xdoclet + jdo is as good as possible > with the current > > state of java (untyped collections). How do you propose to > specify the > > type a container object is supposed to contain without additional > metadata? > > Untyped collections are a big issue. Currently, however, there are > solutions for > serializing amorphous collections (java's built in > serialization and other > mechanisms > support such collections)- but the only general ones I can > think of would > involve > doing something ugly (such as converting the collection to a > blob or clob). > > > How do you propose to specify which classes should be persistent? > > One would specify which classes would need mappings, and the > mapping tool > would examine those classes and generate maps for them. Now, > if one doesn't > know what type of objects will be serialized ahead of time > there would be > no benifit to such an auto-mapper. > > > Maintaining this type of info outside the java file is ludicrous, > therefore > > it needs to be maintained in the java file. > > That's my point. At the same time one doesn't want to "mark-up" code > (obviously > it is very easy to get out of sync doing that) especially for a large > application > with 3rd party modules. > > > Do you have a better idea than javadoc tags? > > As I said before my idea is that the code itself is the > source of its own > mappings. > The standalone mapping program would take "meta-maps" (for > mapping to OJB, > Hibernate, > Castor, or whatever; also to define the "default" and > "specific" behavior > for how classes > map to tables (one table per class...)). The first group of > meta-maps would > be needed > (but general to all classes), and the second group of > meta-maps would be > optional (to > override or fine tune default behavior). > > > One of my clients is using xdoclet + 2 jdo implementations > and it works > > fine, even though the xdoclet jdo templates are very new. > As with any use > > of xdoclet, running the xml generation as part of the build > assures that > it > > is up to date. > > For some that might be fine, but I know my fellow developers > here would not > take kindly to more coding conventions.... Not to mention > the fact that a > large > chunk of what we want to store comes from 3rd party software. > > > In the future we will probably see this kind of metadata > stored directly > in > > class files rather than external xml files, but I think it > will still be > > generated from javadoc tags in the source. > > The way I see it is that most of the information is already > "implied" in the > classes. Of course, the class itself doesn't tell if each > class gets its > own > table (or there are foreign keys to parent classes...), amorphous > collections > are trouble..., but default behaviors and meta-maps might get > around these > issues. > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
