Scot P. Floess wrote:
Steve:
Now that I give this some deeper thought...I see now what the intent
is... I got hung up on dual parsing...one by <sql> task and one the the
JDBC layer: clearly one has to be able to issue a sql statement - thus
the delimiter attribute - duh on my part :(
I do see your point...and well taken ;)
I still think there is a bit of a mess in delimiter handling.
I have forked off some of the code for my own use
http://svn.sourceforge.net/viewvc/smartfrog/trunk/core/components/database/src/org/smartfrog/services/database/core/TransactionImpl.java?view=markup
Not having to care about backwards compat I dont need to worry about
breaking anything. I've tried to be a bit more consistent. As an example
compare its crackCommands() method with SqlExec.runStatements() :-
http://svn.apache.org/viewvc/ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/SQLExec.java?view=markup
Mine is a lot simpler, and I trim off the whitespace before looking for
a delimiter at the end of the line. On the <sql> task, if you have
keepformat=true, then a delimiter followed by whitespace doesnt (on my
looking at the code) appear to get picked up right.
The other dirty secret about <sql> is that, right now, there are no
tests for it. Its one of those things that needs functional testing, not
unit tests. We could (and should) use HSQLDB, but that wouldnt catch
bugs against mssql, oracledb, postgres and mysql.
Although, it still "feels" like there ought to be a way to hand off the
whole file's contents to the JDBC layer and do no parsing in the <sql>
task.
There's no easy way that I know of.
-steve
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
