db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Dudziak <to...@first.gmd.de>
Subject Re: torqueschema bug?
Date Tue, 03 Feb 2004 07:23:41 GMT
On Mon, 2 Feb 2004, Gus Heck wrote:

> 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.

LONGVARBINARY is not really a standard SQL type, only a generic one. SQL
is not really the standard that one would wish for.
The problem that you have is that commons-sql does not seem to produce
valid sql (and is probably not intended to), as opposed to Torque. This is
what Torque generates from the schema:

# -----------------------------------------------------------------------
# TorqueBug
# -----------------------------------------------------------------------
drop table if exists TorqueBug;

CREATE TABLE TorqueBug
(
        id INTEGER NOT NULL,
        nonPersistant LONGBLOB,
    PRIMARY KEY(id)
);
  
This is valid MySql sql code.

 
> 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.

The Torque schema is intended to be database unaware (and thus not
executable as such) as Torque handles database-specific issues
internally. This is actually one of the features of Torque (and the reason
why OJB uses Torque). That is also why the XDoclet OJB module generates a
Torque schema. The intention is that this is then postprocessed by Torque
(using targets in the torque build file, see the module documentation and
the OJB build file, target prepare-testdb) to actually generate correct
creation and initialization sql for the target database (which OJB can't
and won't do), and to execute this sql.
 
> 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.

If that is the case, perhaps Matt Hawthorne could be persuaded to join
forces with the Torque guys ?
 
Tom



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


Mime
View raw message