I think the problem is that you and I are trying to apply Torque (or any other O/R mapper) to a problem it's just not made for. Certainly in our case, I do have trouble seeing the practical application of Torque, because the *implicit* / *business process defined* O/R map for our ERP is hella complex.
I think you've hit on it. Torque is really table-oriented, not business-object oriented. If there's any lesson I can take away from the last few months of wrestling with Torque, it's that table structure should be designed around business objects, not used as the basis for business entities (as Torque seems to encourage). Business objects should practically never be modified to suit some quirk of their persistent storage mechanism. This is probably pretty obvious, I must have been on stupid pills for the last few months. Hindsight.
In my application, Torque has been reduced to a very basic DTO layer. I don't put any logic in any of the generated classes and I use only the storage methods.
I intend to remove Torque entirely and go back to populating objects using SQL. When Torque works, it works all right... but the code generation stages are one big time consuming headache while debugging. And debugging Velocity that generates Java really, really, REALLY sucks.
I have glanced at Hibernate over the past week, and it looks like a good alternative to Torque. I think I'll skip it though. SQL is fine for now in my case.
Gabe
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
