Hi again Stephen Haberman wrote: >> OJB must improve it's forward and reverse engineering capabilities. >> I think that's a point where both projects could come together. > > > I'm slowing starting to agree. > > While it's a bit disappointing to see Torque, or some incarnation of > it, being used only for forward/reverse generation and leaving all of > the cool persistence stuff to OJB, my current view is that it is in > the best interest of both projects. > > So, there are several options for Torque and OJB merging/working > together. > > 1) Assuming Torque dumps it's om/peer generation stuff, it could, > with some refactoring, be completely folded into OJB as it's > forward/reverse generation tool and active development on Torque > would cease (save perhaps for bug fixes to the 3.x line). > > 2) Torque could also dump its om/peer generation stuff, but remain a > separate project that focuses solely on a well-designed, generic > forward/reverse generation framework that OJB could then > extend/customize, ideally with little effort, for it's > forward/reverse generation needs. Ideally, this would also allow > other projects who want to do any sort of DB forward/reverse > generation to build their functionality on top of Torque. > > 3) Torque's sql forward/reverse generation functionality could be > moved to a separate project, something like commons-sql, which really > would probably be exactly like option 2, except without the Torque > name. Torque would then build itself on top of this commons-sql > project to do the om/peer generation it currently does now. > >> From a loyalty to Torque perspective, I like the 3rd option. I >> think we > could build a much cleaner om/peer generation architecture, > especially if a well designed commons-sql framework was available. > However, then we're still competing with OJB. > > However, I think the 2nd option makes more sense in the long term. > Existing Torque users will be kind of miffed, but I think having one > solid implementation of object persistence framework is best. > > I also think OJB should be kept purely an object persistence > framework; any sort of forward/reverse generation should be in a > separate project.
I have no objection to move this stuff to a separate project as this will safe us a lot of work. Of course there must be a very good integration of both tools. > I think the forward/reverse generation stuff would be better designed > and implemented with its own set of committers that are interested > solely in it. (Currently in Torque, the forward/reverse generation > stuff is a lower priority than the Torque core, and I think this > would tend to be the case in OJB, too). Yes, we have that tendency in OJB too. Most developers working on O/R stuff are not that interested in the forward/reverse tools. > > Which option do you (and perhaps what OJB people in general) like, > Thomas? We had no discussions on this issue, so I don't know the other developers opinion (I'll cc this mail to our list, to start a debate.) here are my random thoughts: Features needed in OJB: We have a Metadata repository that contains the O/R mapping information. This repository is loaded from an xml file (repository.xml) on startup. The DecsriptorRepository holds ClassDescriptors for all persistent classes. The DescriptorRepository contains all kind of information that can be used to contruct Java classes and SQL DDL. To have a full forward/reverse engineering we need the following tools: 1. from repository.xml to DescriptorRepository (existing, build with a SAX parser) 1a. from repository.jdo to DescriptorRepository (existing, build with a SAX parser) 2. from DescriptorRepository to repository.xml (existing, build with a recursive toXml() mechanism) 3. DescriptorRepository to Java classes (representing the busines OM) (not yet implemented, I'd prefer a MetaObject approach as in Smalltalk) 4. DescriptorRepository to SQL DDL (we have a prototype for this, but I think we need a much more complete solution) 5. Java Classes (representing the busines OM) to DescriptorRepository. (not yet implemented, no design ideas yet) 6. Form JDBC datasource to DescriptorRepository. (not yet implemented, no design ideas yet) 7. A graphical mapping tool that allows to build a DescriptorRepository manually from existing DB and existing Java classes. (existing, Florian is working on a second release of this tool currently.) 8. In order to generate our testbed database we need a tool that can generate SQL DDL and insert test data in to the db from a XML Schema definition. (implemented with Torque) Tasks 3.-6. are currently not (or only rudimentary) implemented. If technically possible I'd like to see these tasks implemented with Torque. So I'd prefer not to drop the OM and SQL generation features. (With OJB persistent classes do not need to implement any interface nor to be derived from a persistent bases class. Thus the OM codegeneration needed for OJB should be rather simple.) Please get me right: I don't want to urge the Torque group into a specific direction. If we come together to cooperate: excellent! If we continue to work separately: OK, no problem! cheers, Thomas > > Which option do the other Torque devs like? > > Also, if we really want to keep both OJB and Torque around, I think > they should at least have different audiences (or groups of users > each project targets). Doing the same thing or the same people in > different projects is silly. Does the different audiences thing make > sense? > > If it does, can we come up with two valid different audiences? E.g. > OJB is for app servers and Torque is for servlets (I know, that's > completely made up and completely untrue...I just couldn't think of a > better example). > > I dunno, without separate audiences, or separate reasons, for each > project existing, I have a hard time justifying keeping Torque's > om/peer generation around (if either project were to be dropped, I'd > have to assume it's Torque as I think it's way further behind, both > implementation-wise and architecture-wise, OJB). > > Perhaps if Torque morphs into mainly a forward/reverse generation > project, the existing om/peer stuff could be kept around for legacy > support and perhaps with the notion of future refactoring, but then > it still comes out doing the same thing as OJB. > > >> That's not correct! You can choose between 3 predefined access >> strategies 2 of them using reflection, the third using only >> java-beans compliant access. It is also possible to plugin user >> defined > > strategies! > > Very cool. Sorry for my un-informed assumption. > > - Stephen > > > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
