> Anyway, I thought those on the list might be interested why I use Torque and > why I consider it the best Data Mapping tool currently around for my needs. > I have no opinion on whether it should be dropped or not, but we will be > continuing to use Torque for the above stated reasons. For our purposes > Torque is still the best solution.
I agree the features Torque provides are very cool and help rapidly build applications. Even two/three months ago, I couldn't say a bad thing about Torque and planned to use it on every db-related Java project that came up. Then I became a committer. Torque's features are awesome; it's implementation is not. I think a lot of the committers realize this, especially the latter, and would like to move to OJB given that it's implementation of object persistence is more robust than Torque's (and note that it isn't just a matter of overhauling Torque's persistence; given the current code base that task is much harder than it sounds). I agree with you that post-Torque, it'd be real nice to have the XML db schema -> data layer code generation feature. I think the OJB people realize this and have started some simple implementations, but for whatever reason, isn't fully/robustly implemented yet (others please correct me if I'm wrong). Going forward, the Torque/commons-sql schema (or some form of it) could be the base schema from which the SQL DLL files, OJB config files, and data layer source files could be generated. How it works out both in terms of projects and implementation is still a bit up in the air, but I think the feature will definitely be there. I think the current view is that the SQL DLL generation would be the base schema/project. Then OJB could add a simple fa�ade/conversion over the commons-sql schema to it's repository format. And then the yet-to-exist code generation (and reverse generation?) project could add a simple fa�ade/conversion over the commons-sql schema to do the data layer generation. Keeping each of the projects separate would result in a better focus on each task (as both the OJB and Torque developers tend to put higher priority on the persistence code higher rather than the DLL code) but then hopefully for use on projects, each project would integrate nicely enough to easily do the schema -> data layer generation feature. I'm not sure whether this would happen on its own or need either a new project or existing 3rd party project (e.g. Turbine) to maintain the integration. - Stephen -- To unsubscribe, e-mail: <mailto:turbine-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:turbine-dev-help@;jakarta.apache.org>
