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? (actually commons-sql bug?)
Date Tue, 03 Feb 2004 21:57:26 GMT
On Tue, 3 Feb 2004, Gus Heck wrote:

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

Well, your scenario is much more involved then what I had in mind for the 
db handling stuff. I only wanted to have something nice to setup the 
database which does not require much configuration (as torque does).
Though I plan to add data insertion, the db handling stuff is certainly
not intended to do such complicated things.

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

This is because all it does is calling the torque/ant tasks. Initially I
wanted to use the torque api directly, but besides the tighter dependency
it would have been much more involved as the torque ant task aren't simple
wrappers but actually do quite some stuff.
FileSystem actions aren't usually a problem for webapps though as
temporary file handling is supplied by java itself.

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

That's true though this has somewhat improved with ant 1.6.0.

Could you perhaps send me some notes on how you use commons-sql for
manipulating the database ? I planned to a howto concerning database
setup/initialization and for this it would be quite helpful!


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

View raw message