In my application database schema a number of my tables include foreign-key references to TURBINE_USERS and TURBINE_GROUPS. To make this work I currently redefine these tables at the bottom of my application database schema (a cut and paste from turbine-schema.xml). With this set up the two tables mentioned are generated twice and I end up with two sets of peer classes - not a very tidy solution, but it works. I'm wondering if there is a better way of achieving the same result. In database.dtd I notice a number of table element attributes that may actually provide what I need, but I am unsure of the combination of attributes to use. Here is the definition of the table element from database.dtd: <!ELEMENT table (column+,(foreign-key|index|unique|id-method-parameter)*)> <!ATTLIST table name CDATA #REQUIRED javaName CDATA #IMPLIED idMethod (idbroker|autoincrement|sequence|none|null) "null" skipSql (true|false) "false" abstract (true|false) "false" baseClass CDATA #IMPLIED basePeer CDATA #IMPLIED alias CDATA #IMPLIED > I was thinking that skipSql might be part of the answer, however I remembered that my currently generated BaseTurbineUser class has a whole bunch of get methods that join back to my application tables. I am now thinking that I may be better off keeping the duplicate table definitions but providing baseClass and basePeer attributes presumably so that the application classes extent the classes generated by turbine-schema. Am I thinking along the right lines or have I got it all wrong? I am assuming that linking from application tables to turbine tables is a common requirement and that database.dtd and torque allow for this. Thanks, Scott --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
