SQL task testing and gump

[Kev Jackson <ke...@it.fts-vn.com>]

Hi all,

Given the recent sql task bugs and realization that the tests are awol, 
which databases could possibly be supported by Gump for testing?

I'd imagine that there are both license and technical issues to deal 
with regarding deploying multiple databases to test SQL task against 
them.  Could we at least have a default database configured as a testbed 
for functional testing (although the line between unit and functional 
tests blurs when dealing with sql in general)?  My suggestion would be 
eaither HSQL or Derby (since it's an apache project).

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

Other obvious candidate databases would be any O/S one (Postgresql, 
firebird, Ingress) MySQL has a weird license that causes some people to 
steer well clear - although it's supposed to be GPL.  Oracle as it's 
probably one of the most 'popular' (read most deployed, not most liked 
by developers).  All of these though will cause a burden on the build 
machines, just to test the <sql> task.

So, I think there are two ways of testing this:
1 - simple test against low end system (HSQL), which will only verify 
basic functionality - 'do the simplest thing that could possibly work'
2 - start from scratch with a new version of the sql task, refactoring 
out the db specific parts and providing a basic functionality only, 
letting someone else maintain the db specific parts (maintaining and 
testing a task that must support 5+ database engines is going to be very 
hard) - break BWC or have an 'old' sql and a 'new' sql

I personally think that working out what to test and how to test and 
what the dependencies are will be a challenge in itself.

Kev

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

Re: SQL task testing and gump

[Stefan Bodewig <bo...@apache.org>]

On Fri, 20 Jan 2006, Kev Jackson <ke...@it.fts-vn.com> wrote:

> Derby is mostly interesting as the syntax is (almost exactly) the
> same as DB2, so essentially you get to kill two birds with one stone
> (syntax tests wise anyway).  Hope that translates to non-native
> English ant people :).

Germans would slay two flies with one hit (actually with one "Klappe"
but I don't manage to translate "Fliegenklatsche" right now).

> My only problem with it was that the db engine itself is an apache
> licensed download from apache.org, but the jdbc driver (last time I
> played with it) was only available from IBM (requiring registration
> to login and download) - can't get to the website to check right now
> if the jdbc driver is available direct from apache yet.

Licenses are not a problem at all in this scenario.  License is only
important if we'd distribute the JDBC driver or if our code was
dependent on the JDBC driver and the driver used some kind of viral
licensing.

Stefan

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

Re: SQL task testing and gump

[Kev Jackson <ke...@it.fts-vn.com>]

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

Derby is mostly interesting as the syntax is (almost exactly) the same 
as DB2, so essentially you get to kill two birds with one stone (syntax 
tests wise anyway).  Hope that translates to non-native English ant 
people :).

My only problem with it was that the db engine itself is an apache 
licensed download from apache.org, but the jdbc driver (last time I 
played with it) was only available from IBM (requiring registration to 
login and download) - can't get to the website to check right now if the 
jdbc driver is available direct from apache yet.  I even had a trawl 
through the source code for the main project, looked like it needed a 
*lot* of cleanup to remove commented out code, unused variables (and 
references to Cloudscape in javadoc...) etc - PMD had a fit :).  So 
commercial code hey - not so nice when you get a chance to lift the lid.

Oracle now have a 'lite' database which is free to use on single 
processor machines (AFAIK), so to test on Oracle isn't outside the 
realms of possibility, but it's a pain in the arse to configure 
correctly, and it's not friendly wrt memory consumption - I'd definitely 
think again before running it on Gump - even if it's almost a 'de facto' 
standard that is most used in 'enterprises' and would be of benefit to 
test features against.

Kev

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

Re: SQL task testing and gump

[Ken Gentle <j....@acm.org>]

At 06:28 2006-01-19, you wrote:
>Stefan Bodewig wrote:
>>On Thu, 19 Jan 2006, Kev Jackson <ke...@it.fts-vn.com> wrote:
>>
>>>Given the recent sql task bugs and realization that the tests are
>>>awol, which databases could possibly be supported by Gump for
>>>testing?
>>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
>>>them.
>>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
>>zero.
>
>
>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
>>>with.
>>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.
>
>-steve
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
>For additional commands, e-mail: dev-help@ant.apache.org
>



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

Re: SQL task testing and gump

[Steve Loughran <st...@apache.org>]

Stefan Bodewig wrote:
> On Thu, 19 Jan 2006, Kev Jackson <ke...@it.fts-vn.com> wrote:
> 
>> Given the recent sql task bugs and realization that the tests are
>> awol, which databases could possibly be supported by Gump for
>> testing?
> 
> 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
>> them.
> 
> 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
> zero.


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



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

-steve

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

Re: SQL task testing and gump

[Stefan Bodewig <bo...@apache.org>]

On Thu, 19 Jan 2006, Kev Jackson <ke...@it.fts-vn.com> wrote:

> Given the recent sql task bugs and realization that the tests are
> awol, which databases could possibly be supported by Gump for
> testing?

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

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

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.

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

I'd expect it to be a good choice just because it is in memory and we
wouldn't need any setup.

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

Stefan

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