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 20:52:58 GMT
Hmm, TorqueDBHandling, while probably great for a one-time deployment, 
but it doesn't look like a good solution for me.

It looks like it does the one time push into the db bit, but for 
development the commons-sql SQLBuilder.alterDatabase() is smoother 
because it atuomatically figures out if the stuff is already there and 
alters, drops or creates whatever is needed. If I use TorqueDBHandling I 
will need to set things up to drop everything (maybe this is automatic?) 
and then reinsert everything every time I reload the application to test 
my code (I think this is true least from brief reading the code of 
TorqueDBHandling. I could be wrong). This means data is always lost, and 
if I am working on an interface mechanism to sort a list of objects in 
the db and put the results in an HTML Table (for example) I have to 
either write something programatic to insert the objects, or re-enter 
them every time. With the commons-sql system, the DB is only touched if 
I am changing persistant classes. This means that redeploying a new 
version with some changes to the Strust front end would tend to blow 
away the database unless I code in some sort of contingency. Come to 
think of it restarting the container might blow away the database too 
without some sort of markerfile to prevent re-invocation of 
TorqueDBHandling code!

Secondly, much of the TorqueDBHandling class appears to rely on writing 
to a filesystem e.g.:

            outputDir = new File(getWorkDir(), "sql");
            outputDir.mkdir();

This is less than ideal for code existing in web apps. Web app aside,

schema -> memory -> DB

is nicer than

schema -> memory -> Filesystem -> DB.

commons-sql doesn't require the filesystem because it will write the sql 
to a stream (so I give it a StringWriter) and then once I convert that 
to a string, the 
org.apache.commons.sql.util.DDLExecutor.executeBatch(String) method 
takes it from there.

Finally, putting ant.jar (and perhaps some of it's dependancies? what if 
I wind up needing 2 parsers or 2 versions of the same parser?) in my 
WEB-INF/lib seems well... excessive. I like ant, but it contains an 
awful lot of stuff that is irrelevant to the sql creation process. It 
would be nice to rely on a more focused library than ant.jar.

- Gus

Thomas Dudziak wrote:

>On Tue, 3 Feb 2004, Gus Heck wrote:
>
>  
>
>>googling  this doesn't turn anything up... TorqueDBHandling 
>>site:db.apache.org
>>    
>>
>
>It's a class in CVS
>(http://cvs.apache.org/viewcvs.cgi/db-ojb/src/java/org/apache/ojb/broker/platforms/).
>The site reflects rc5 where it wasn't part of yet.
> 
>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