ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ken Gentle <>
Subject Re: SQL task testing and gump
Date Thu, 19 Jan 2006 16:45:29 GMT
At 06:28 2006-01-19, you wrote:
>Stefan Bodewig wrote:
>>On Thu, 19 Jan 2006, Kev Jackson <> wrote:
>>>Given the recent sql task bugs and realization that the tests are
>>>awol, which databases could possibly be supported by Gump for
>>Just look over the project's built by Gump.  hsqldb and derby are both
>>there and would allow to be run as embedded databases AFAIK.
>>>I'd imagine that there are both license and technical issues to deal
>>>with regarding deploying multiple databases to test SQL task against
>>Given that Gump runs on multiple machines (two right now, should be
>>more) and we are very low on infrastructure volunteers it is probably
>>save to assume that the chance of installing anything is very close to
>Leo and I have been discussing java1.5 support; I may be able to 
>devote some time to do that.
>>MySQL is part of Gump's own requirements, but I'm a bit reluctant of
>>adding a database instance for Ant's tests.  This is a matter of
>>setting precedence and having to do it for other projects as well and
>>all that.
>+security/account issues.
>>>Problems with HSQL are the fact that it's in memory, so it may not
>>>be representative of the databases that <sql> will generally be used
>>I'd expect it to be a good choice just because it is in memory and we
>>wouldn't need any setup.
>you can get HSQL to persist. Its a matter of the right JDBC URL. For 
>the level of testing I'm planning, in-memory works well.
>We ought to be able to run a sequence of <sql> commands in the same 
>build file and have them all share the same db instance.
>Also, its nice and fast because its not quite as 'enterprise grade' 
>as, say mysql, which makes tests nippy.
>Ken, what tests were you thinking of?

I've never had much trouble with really basic query stuff in the SQL 
task;  The problems or limitations have been platform specific (read: 
Oracle) or script related (also read: Oracle).

Derby is cool, wasn't too hard to install at all.  The SQL support is 
different than Oracle, more like DB/2 (big surprise there).

Tests for "onError", "delimiter", "delimterType", "keepFormat" on 
either files or embedded text are where I'd focus, I think, because 
they *are* platform specific.  IIRC the history of this task 
correctly, all of those attributes were added to support loading 
Oracle PL/SQL procedures and SQL/PLUS scripts.

"onError" is really subjective, depending on what you're executing - 
a table drop before recreating it is standard procedure, but the 
"table or view does not exist" *is* an error

Testing aside for the moment, this is one of the reasons that I think 
the "decorator" idea has merit.  Let the JDBC class create the DB 
specific decorator, or a generic pass through if no db is 
specified.  BWC is maintained if the addition of the "decorator" is 
driven from YAA (yet another attribute).

Here's my suggestion:

0.  Convince my boss and my wife that this is really beneficial for 
the world at large and is worth the investment of some work and 
leisure time. ;^)

1.  Develop base tests for current behavior using what ever is 
readily available on Gump (sounds like HSQL and Derby), using DBUnit 
for basic CRUD testing verification.  I think we should assume a 
schema, not including schema script generation in the base tests of 
the SQL task.

2.  Refactor JDBC/SQL to allow for db specific decorators:
     * Extract the java interface to the SQL task.
     * Rename the existing SQL task to CoreSql or BaseSql, 
implementing the interface.
     * Edit JDBC to invoke via I/F
     * Retest.

3.  Create a "pass-through" decorator, 100% delegation of all methods 
to the CoreSql code.
     * Refactor SQL to use it.
     * Retest.

4.  Create HSQL and or Derby decorators.  Unfortunately, I don't know 
what I'd put in these - my particular itch is around the Oracle specifics.

5.  Open the door for some "community" development/testing of the 
commercial platforms.

>>>Last time I tried Derby, it required a client download from IBM -
>>>this instantly made me fairly annoyed, and I'm not sure about the
>>>license of the client, but it certainly dampened my enthusiasm for
>>>the project.
>>I've never tried Derby myself.  The JDBC driver wouldn't cause big
>>problems since just downloading stuff and providing them on the
>>CLASSPATH is something I'm willing to do on the Gump machines (see
>>"installed packages").
>Not looked @ derby. DB-config/support in Smartfrog is on my lower 
>priority todo list for march, but I was going to focus on mysql 
>because its one we have a private component for that can just be 
>pulled into the public repository with the addition of an adequate 
>set of unit tests. If we did derby afterwards (very low priority, 
>I'd give oracle more time), then I'd know about installing/using it.
>To unsubscribe, e-mail:
>For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message