Thanks for sharing your thoughts. I will investigate the ddlutils
project since it seems indeed better suited to our needs at this point.
And thanks to the XML format compatibility this will not stop us using
Torque's other tools in the future.
Thanks,
Robert
Thomas Fischer wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
