db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gus Heck <gus.h...@olin.edu>
Subject Re: torqueschema bug?
Date Mon, 02 Feb 2004 18:45:26 GMT
Attached is code that recreates the problem, and the schema generated 
from it by the torqueshema xdoclet/ant task. The problem can be 
demonstrated using the TorqueBugMain class.

As I think about it a bit, if LONGVARBINARY is really the standard sql 
type and adding the space is a MySQL quirk, I am not sure if this is 
torqueshema's responsibility. I had it in my head that since 
torqueschema was part of OJB it would be aware of what database we were 
using, but as I look at it, I have begun to realize that torqueschema is 
oblivious to the database type. So in some sense perhaps it is the sql 
generator (commons-sql) that should be aware of the database type.

The other parts of OJB already have solved the "talking to MySQL" 
problem, so it would seem a little silly for commons-sql to have to 
duplicate that separately. In the tutorials for ojb doclet, the 
torque-build.xml file is used to insert the sql into the database, which 
is probably what the tests are doing too.

I _suspect_ that there is also duplication of sql generation 
capabilities between torque and commons-sql. Commons-sql is or was (I 
believe) an endeavor that hoped to create sql generation mechanisms that 
could be used both by torque and other projects. So currently I suspect 
the real problem is that the MySQLification occurs after the generation 
of the project.xml. So some things that be good would be if torqueschema 
could be (optionally) target DB aware, or the project.xml could be 
re-processed to account for MySQL, or Some part of OJB could expose the 
"convert to Specific DB quirks" functionality or even better, the magic 
DB compatibility stuff could get put in commons-sql and the SqlBuilder 
class could account for the specific target db.... which OJB could take 
advantage of.

I believe that the commons SQL had hoped to become part of db.apache at 
some point. Being none to active, commons-sql might need to have some 
additional help from people here (like whomever takes care of the DB 
compat stuff here could help do it there) to make sure it keeps up with 
peoples needs. Best of my knowledge is that the only one working on 
commons-sql right now is Matt Hawthorne. Certainly he is the only one I 
have seen do any commits in the last 2 months, though it is possible 
that my filter missed something.


View raw message