Hi, Long time lurking. We have two major engineering operations based on Turbine 2.1 and Torque. Several aspects of Turbine and Torque have liberated our software process, especially in the area of ability to support rapidly changing customers, markets, requirements and business models.
> 3) Torque doesn't hold a candle to OJB. and, > Torque's three main features are Java code generation, DDL generation, > and persistence. DDL generation is being handled very nicely by > commons-sql, persistence is handled nicely by OJB, but as of yet, > there isn't really a Jakarta project for Java code generation. Instead > of making this an argument for keeping Torque around. >From my perspective Torque is probably the major reason Turbine is so useful to us. In our engineering business, we support a direct model, so if the software cant keep up with the business model, or the software becomes obsolete to the business model we are unable to capitilise on new revenue streams. This moves pretty fast as well, and it isnt uncommon for new functionality to be added and requested with turn around times of one day. It may be as simple as a customer refusing to pay an invoice until they see a "received by" field on the invoice, or a complex structural change requiring that Work Orders show partially billed states to the customer through their history. Even though our developers differentiate between trivial changes and structural changes, customers dont. ie the "all I need is a button which .... ". Previous to Torque in our software systems, the database was the rate determining step. Any change that propogated down to a data structural change was a pain in the arse and took far too long. It meant the database schema had to be modified, the data mapping layer and then the business objects to the view. This caused large differences in the turn around time of requests to be implemented, if it touched the database, we were subject to the tyranny of a schema change. We have a highly fluctuating data model, it has changed from 60 tables to 93 in fourteen months of production, this is despite pushing more transient data into XML repositories. Our schema.xml has gone through 61 check-ins since being in production as well. Having a code generation tool that can efficiently support that type of data structure volatility is pretty important to us. With Torque this type of change is a quick XML edit and running of a shell script. In essence it has allowed me to make to refactor the database schema and structure with confidence. Previously we used to get a complex schema that was designed to be monolithic, with Torque, I dont have to treat the data schema more carefully or with any more persistance, than any other layer in the system. The Torque code generation is the main reason for this. I have had a look at OJB, but as there wasnt any code generation abilities that I could determine in the same manner as Torque, I saw no personal reason to switch. Torque is working extremely well for us and I am thankful to all the people who have worked on Turbine and Torque, it has allowed me to meet my customers demands with a superior solution. 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. Cameron Riley -- To unsubscribe, e-mail: <mailto:turbine-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:turbine-dev-help@;jakarta.apache.org>
