You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-user@db.apache.org by Joerg Heinicke <jo...@gmx.de> on 2004/03/09 15:28:53 UTC

xdoclet + torque + mysql

Hello,

until now I could successfully use xdoclet to generate the torque schema and
torque to generate the sql script for the database. This worked upto 8 or 9
elements, with the next one I got a foreign key constraint into the torque
schema, what is not bad at all. But torque generates a sql script out of it,
that mysql does not like:

ERROR 1005: Can't create table 'bla.frm' (errno: 150)

This seems to be an infamous problem as different postings in FAQs and mailing
lists show, e.g. http://www.faqts.com/knowledge_base/view.phtml/aid/23462/fid/83.

For the moment I caould circumvent it by adding generateForeignKeys to the
xdoclet task, but that does not really satisfy me.

So I have some questions:
1. Why is this now the first reference with the foreign key constraint added to
the torque schema? I had already collections and references to an abstract
class, never a foreign key constraint was added. Having those in general would
be good I think for the case of changing the persistence layer.

2. Though I guess there is a more appropriate torque mailing list:
Why does torque generate a non-working sql script though the profile is
specified with mysql? Is there a mysql/innodb profile that changes that
behaviour?  Of course I don't want to learn just another templating language for
fixing this myself:
http://www.mail-archive.com/torque-user@db.apache.org/msg01050.html.

3. Even less appropriate here:
Why is mysql that dumb, and does not resolve the dependency on a foreign key
index itself? Maybe somebody does know a switch to activate the intelligence in
mysql :)

Joerg


---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org


Re: xdoclet + torque + mysql

Posted by Thomas Dudziak <to...@first.gmd.de>.
On Tue, 9 Mar 2004, Joerg Heinicke wrote:

> until now I could successfully use xdoclet to generate the torque schema and
> torque to generate the sql script for the database. This worked upto 8 or 9
> elements, with the next one I got a foreign key constraint into the torque
> schema, what is not bad at all. But torque generates a sql script out of it,
> that mysql does not like:
> 
> ERROR 1005: Can't create table 'bla.frm' (errno: 150)
> 
> This seems to be an infamous problem as different postings in FAQs and mailing
> lists show, e.g. http://www.faqts.com/knowledge_base/view.phtml/aid/23462/fid/83.
> 
> For the moment I caould circumvent it by adding generateForeignKeys to the
> xdoclet task, but that does not really satisfy me.
> 
> So I have some questions:
> 1. Why is this now the first reference with the foreign key constraint added to
> the torque schema? I had already collections and references to an abstract
> class, never a foreign key constraint was added. Having those in general would
> be good I think for the case of changing the persistence layer.

Foreignkeys are only generated when both endpoints of the
reference/collection are fixed, i.e. no inheritance on either end with
differing tables.
 
> 2. Though I guess there is a more appropriate torque mailing list:
> Why does torque generate a non-working sql script though the profile is
> specified with mysql? Is there a mysql/innodb profile that changes that
> behaviour?  Of course I don't want to learn just another templating language for
> fixing this myself:
> http://www.mail-archive.com/torque-user@db.apache.org/msg01050.html.

Indeed, this is a question better asked on the torque-user mailing
list. It might have been solved in Torque 3.1 (we use 3.0.2) but this is
not yet directly supported by OJB (but might work).

> 3. Even less appropriate here:
> Why is mysql that dumb, and does not resolve the dependency on a foreign key
> index itself? Maybe somebody does know a switch to activate the intelligence in
> mysql :)

Don't know about that, but more 'intelligence' (guessing in this case) in
the database means more restriction on the usage.

Tom


---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org