Bug 38807 - Add an errorproperty parameter to <sql> task, like the junit task's
Summary: Add an errorproperty parameter to <sql> task, like the junit task's
Status: RESOLVED FIXED
Alias: None
Product: Ant
Classification: Unclassified
Component: Core tasks (show other bugs)
Version: 1.6.5
Hardware: PC Windows XP
: P3 enhancement (vote)
Target Milestone: 1.8.0
Assignee: Ant Notifications List
URL:
Keywords: PatchAvailable
Depends on:
Blocks:
 
Reported: 2006-02-28 13:44 UTC by Andrew Stevens
Modified: 2009-08-24 07:09 UTC (History)
0 users



Attachments
Patch for SQLExec task (2.28 KB, patch)
2006-03-02 02:50 UTC, Andrew Stevens
Details | Diff
Patch for 1.6.x branch (3.14 KB, patch)
2006-03-03 02:27 UTC, Andrew Stevens
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Stevens 2006-02-28 13:44:30 UTC
I'm using the <sql> task with a fileset to read in a whole bunch of stored proc
definitions into our unit test database prior to running the tests.  Although I
could use onerror="abort" (or stop) to make the build fail if there are any
problems, this only reports the first file.  What I'd find more useful would be
to use onerror="continue" in conjunction with an errorproperty attribute (like
the junit task has) so that all the errors appear in my log file, but a property
gets set which I can check later in the build (and either fail or skip the unit
tests).
And, while I'm wishing, a warningproperty property which gets set if the
conn.getWarnings() call returns anything in execSQL() might also be useful.
Comment 1 Steve Loughran 2006-02-28 14:47:02 UTC
I see what you want here andrew, but I'm not sure what we are going to do about
it. To an extent the error handling of ant is a bit, well, messy; we have
limited policy hard coded into the tasks themselves.

Take a look at the ant-contrib project on sf.net, in particular their try/catch
task. Then look at <macrodef> and see what it would take to actually implement
what you want in a macro. something like (

<macrodef name="mysql">
 <attribute name="errors"/>
 <attribute name="file" />
 <sequential>
<trycatch property="errormessage" >
  <try>
   <sql >
    <transaction file="@{file}" />
   </sql>
  </try>
  <catch>
   <echo level="verbose" >${errormessage}</echo>
   <property name="@{errors}" value="${errormessage}"/>
  </catch>
</trycatch>
</sequential>
</macrodef>

If you fill the <sql> bit in with your DB connection, you get a task you can use
like
 <mysql errorproperty="errs" file="drop-db.sql" />
 <mysql errorproperty="errs" file="create-db.sql" />
 <mysql errorproperty="errs" file="create-user.sql" />
 <mysql errorproperty="errs" file="populate-db.sql" />

-steve
Comment 2 Andrew Stevens 2006-03-02 02:49:16 UTC
> I see what you want here andrew, but I'm not sure what we are going to do about
> it. 

Does the attached patch help the decision any? :-)

>To an extent the error handling of ant is a bit, well, messy; we have
> limited policy hard coded into the tasks themselves.
> 
> Take a look at the ant-contrib project on sf.net, in particular their try/catch
> task. Then look at <macrodef> and see what it would take to actually implement
> what you want in a macro. something like (
> 
> <macrodef name="mysql">
>  <attribute name="errors"/>
>  <attribute name="file" />
>  <sequential>
> <trycatch property="errormessage" >
>   <try>
>    <sql >
>     <transaction file="@{file}" />
>    </sql>
>   </try>
>   <catch>
>    <echo level="verbose" >${errormessage}</echo>
>    <property name="@{errors}" value="${errormessage}"/>
>   </catch>
> </trycatch>
> </sequential>
> </macrodef>
> 
> If you fill the <sql> bit in with your DB connection, you get a task you can use
> like
>  <mysql errorproperty="errs" file="drop-db.sql" />
>  <mysql errorproperty="errs" file="create-db.sql" />
>  <mysql errorproperty="errs" file="create-user.sql" />
>  <mysql errorproperty="errs" file="populate-db.sql" />

That won't work with a fileset, though, will it? (I don't much fancy having to
add another line every time there's a new stored proc)  And even if I could come
up with a similar macro that passed through a fileset, it would still stop after
the first sql file & statement that threw an error (at least, the first from
each call to the macro), instead of dumping all the errors to the log.  Or am I
missing something?
Comment 3 Andrew Stevens 2006-03-02 02:50:28 UTC
Created attachment 17815 [details]
Patch for SQLExec task
Comment 4 Andrew Stevens 2006-03-03 02:27:38 UTC
Created attachment 17822 [details]
Patch for 1.6.x branch

Same patch, backported to ANT_16_BRANCH.
Comment 5 Stefan Bodewig 2009-08-24 07:09:48 UTC
svn revision 807228