At 06:28 2006-01-19, you wrote:
>Stefan Bodewig wrote:
>>On Thu, 19 Jan 2006, Kev Jackson <kevin.jackson@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
|