Forgive me if I'm beating a dead horse here, but I don't think I've made my point all that well in this thread. And now I finally had time to read up a bit more and see what's been going on.
It's always been somewhat difficult to define what Torque is. I always thought that the primary function of Torque was to use Velocity templates, and an XML definition file, and ant to generate code for Object-Relational mapping. The Torque 2.1 code makes no attempt to be a generalized persistence mechanism. It does not work with anything but SQL, it doesn't provide support for any kind of locking, or concurrency management, and it doesn't even fully abstract the code from the underlying SQL engine. (For instance in Criteria, it is still sometimes necessary to use custom Criterion containing SQL syntax snippets) Until 3.0+, there wasn't even a cacheing mechanism. So Torque to me is a middle of the road solution. It saves a lot of work when you want to access the DB directly for simple things, but it's not a complete "enterprise" persistence mechanism. Fine, keep it that way. It still serves a useful purpose. It seems to me that the code that was generated with Torque 2.1 used the Village API for conveninence. It turned out that a lot of the code that would have been generated was completely static, so this code was extracted into the BaseObject and BasePeer classes. That code could just as easily have been embedded in the templates. Perhaps it should have, because then it would make the generated objects less brittle in that they can't be broken by replacing the turbine.jar with classes that don't work properly with the generated code. When I started looking into making the code work using PreparedStatements (without Village), I saw places where I'll probably need to change the code templates to make things work well (or at least simpler). If that's the case then you really should consider the generated OM objects and the BasePeer, BaseObject classes all the same beast. I think of them as one type of generated code that Torque can produce. Now I see that in 3.0, the Velocity and XML has been used to generate the OJB XML definition and basic objects. This is awesome. OJB sounds fantastic, and I'm psyched that Torque is providing a way for it's users to MIGRATE to using OJB. The generated objects for OJB don't use BasePeer, or Criteria or any of the code that may or may not have been considered part of Torque, so I consider those new templates a great way to migrate from the old code to the new code. But it's not a drop-in replacement for my old Torque generated OM classes. To use the new OJB code, I need to use the OJB API to retrieve and store objects myself. That's the way it should be. So if somebody wants to add templates that generate classes that use player, or any of these other persistence APIs, then that's fine, as long as the user is able to pick and choose what type of code is generated. If I want to start using player in my code, then I can use Torque to generate my code. But I really think trying to adapt the old OM/Peer code to work with any other persistence or SQL abstraction API is going to be fraught with problems and is not worth the endeavor. - Chris P.S. But I'd also like to add that to truly make Torque useful, it would nice if the end-user could add business specific stuff into the XML definition and tailor their templates to generate code specific to their business. Ideally, the standard database.dtd could be included in a business specific DTD, and the data would be mapped automatically to the objects that are passed to the templates. This would probably require using JAXB or some new XML binding technology to really do this properly. __________________________________________________________________ The NEW Netscape 7.0 browser is now available. Upgrade now! http://channels.netscape.com/ns/browsers/download.jsp Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/
