I am afraid to say this, but the part of Torque which creates a schema from jdbc metadata is not the best part of Torque. Although I did not check in detail, most limitations you describe come from the fact that informations are not available in JDBC metadata (although I'm not so sure about discarding the information about indexes and auto increment)
I'd suspect that if you do not want to use the OR-Mapping part of Torque, there are better tools than Torque for database reverse engineering. It is not Torque's main focus. E.g., you may want to check ddlutils (http://db.apache.org/ddlutils), a project which is more active in this field and which should even produce an xml schema which can be used by the Torque generator. Thomas Robert Enyedi <[EMAIL PROTECTED]> schrieb am 03.08.2006 16:02:34: > Hi, > > We are evaluating the Torque Generator for using it in our product. We > have heard many good words about the Torque project and we would like to > become faithful users and maybe even contributors :-) > > Currently we use a MySQL 4 database in the back-end. We would like to > also be able to use the Derby and Oracle database engines. For this the > critical part is to have our current MySQL schema transformed into the > Torque XML DB schema. > > Using the torque-jdbc-transform Ant task, I have tried to extract the > Torque XML DB schema from our existing database. While generally > correct, the result had some things missing though: > - the ENGINE=MyISAM option is present for some of our tables. Is there > something equivalent in Torque? > - the FOREIGN KEY REFERENCE ON DELETE SET NULL sequence is completely > discarded, > - the UNIQUE and ON DELETE CASCADE clauses are discarded, > - information on INDEXES is discarded, > - information on AUTO INCREMENT fields is discarded. > > Could these be due to the limited database meta-information provided by > JDBC? > > From the generated schema I generated back the MySQL schema and saw > some type mapping inconsistencies: > - INTEGER was generated as MEDIUMINT (I found this to be a but fixed in > the 3.2.1 development branch), > - DATE was generated as DATETIME, > - DATETIME was generated as TIMESTAMP (this is correct, though starting > with MySQL 4), > - BLOB becomes LONG BLOB, > - BINARY NOT NULL becomes only NOT NULL (this is bad when storing case > sensitive strings, like path names), > - MEDIUMTEXT becomes TEXT. > > Did someone encounter these issues? Do you have solutions to them? > > Manual editing of the XML DB schema is an option, but can all these > constraints be represented in the Torque XML DB schema? > > Thanks, > Robert > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
