At 06:28 2006-01-19, you wrote:
Stefan Bodewig wrote:
On Thu, 19 Jan 2006, Kev Jackson <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
