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? (actually commons-sql bug?)
Date Tue, 03 Feb 2004 16:58:48 GMT
Thomas Dudziak wrote:

>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), 
>
I'm relatively sure they intend to. This is now looking like a bug in 
their MySqlBuilder class. I will file that with them.

>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.
>
> 
>  
>
Yup, works for me.

>>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 
>
Yes I read the docs, but I want this done at runtime not build time so 
that the build infrastructure is not needed to deploy the war against a 
given database. If everything I have in place works (and the 
MetadataManager/password issue is resolved) then deploying my app should 
be no more than 3 steps... 1. create the database account. 2. edit the 
OJB properties for the account name, password and db info in the 
warfile. 3. drop the warfile into the container and access a db-aware 
page. Presto.

>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 ?
>  
>
Dunno about that, but perhaps. commons-sql seems to have come from 
Torque/Turbine, so there are probably reasons for being separate, but 
I'm cc-ing him on this to see what he thinks.

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



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