Bugs fixed in this release
--------------------------
- Partial functionality was not working for either resultset or row. Bug pointed out by Meghanath and Chris Snow.
- assertion "outparams-equal" changed to match on id instead of position, to make it similar in behavior to resultsets-equal. The feature was triggered by a problem matching partial outparams reported by Greg Vatman.
Changes in this release
-----------------------
- New JARs added to lib: commons-jexl-1.0.jar to support the ExpressionMatcher functionality, and commons-logging.jar to satisfy dependencies for commons-jexl-1.0.jar.
New Features in this release
----------------------------
- new result attribute echo, if set to true, will print the generated result. - new assertion "none" to do no matching and always report success, requested by Meghanath.
- new assertion "not-exception" to assert that the result is not an exception, requested by Meghanath.
- new XSLT based Transform tool to convert legacy XML into SQLUnit test files, based on a request from Meghanath.
- new ExpressionMatcher that can be used to match using conditional expressions written in JEXL, based on a feature request from Craeg Strong. JEXL syntax is explained at their page: http://jakarta.apache.org/commons/jexl/reference/index.html
- DOCTYPE SYSTEM id no longer needs to point to a relative or absolute file path to reference the sqlunit.dtd file. It is now supplied as part of the JAR file. Simply specifying sqlunit.dtd in the system id will reference the sqlunit.dtd file as a resource from the JAR file. This was based on a requirement from Greg Vatman to point to the sqlunit.dtd file in a web environment. Note that this change is backward compatible with the existing way of specifying it using file:/relative path or file:/absolute path too, so existing tests dont need to change.
Please let me know if you see any problems.
Thanks
Sujit
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Here is a sample stored procedure and SQLUnit tests that will expose this problem
create procedure SQLUnit_TestMultipleOutputParams
( @param1 integer,
@param2 integer,
@param3 integer output,
@param4 integer output
)
as
begin
set nocount on -- Don't return number of rows affected
I havent had a chance to run the sproc yet, since I dont have access to a Sybase database at the moment. BTW, if you could check to see what you are getting by replacing the <result>...</result> part of the tests with a <result echo="true" /> that would be very helpful too.
As to what the error message means:
outparam[2].id(10) out of bounds ==
A second outparam in the result (by position) has the id="10", and SQLUnit does not find 10 outparams returned from the sproc call, and hence cannot match.
However, your test does not have outparam id="10" anywhere, I thought it may be a bug where I pull the text value in instead (outparam id=4 is 10 in both tests), but I did a quick check, and the code does pass the id attribute correctly, so maybe I am missing something and need to look more closely.
This is indeed due to a change in SQLUnit 4.8, and I apologize for breaking existing functionality, but I see that you are using the id as a shorthand to indicate the position of the parameter. SQLUnit did not care about the ids so far, it matched only by position, but as of SQLUnit 4.8 it allows you to specify the outparams partially, so for example, you could specify the 2nd and 3rd inouts only if you did not care about the first out parameter and SQLUnit will only match the ones you specify. I need to match by id for this.
Not sure how much work it would be for you, and I apologize again if its a lot, but if you replace the id=(1,4,5) in your tests to (1,2,3) to reflect the outparams that are coming back, then your tests should run fine.
To specify details about the outparams, you could use the name attribute, which is currently unused and is likely to be so, since it was created for this very purpose.
But the (10) coming back in the error message is a bug, I will see why thats happening and let you know.
-sujit
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I apologize for the confusion. I should have been more explicit with my
responses.
My original response was with respect to another test I was running.
One that called a stored procedure that has 10 parameters. The second response
was a stored procedure/test pair that exposed the issue that I was seeing
(without having to send you my original stored procedure/test pair).
The error I receive with the stored procedure/test pair in my second response is:
net.sourceforge.sqlunit.SQLUnitException: outparam[2].id(4) out of bounds
So there should be no bug with respect to where you pull the text value
(at least as far as I know).
I used the id attribute, since it is required according to the SQLUnit
documentation online (see http://sqlunit.sourceforge.net/c460.html#AEN1575
for <param> and http://sqlunit.sourceforge.net/c460.html#AEN2162 for <outparam>).
Since the id attribute is one-based to follow the JDBC specification, I have
based all my id values on the position of the parameters, including the
output parameters. I believe the JDBC specification uses positional parameters
regardless of "in" or "out" status, in the same manner.
You indicated that "SQLUnit did not care about the ids so far", but that is not
clear within the documentation. In fact, as recently as SQLUnit 4.7
the stored procedure/test pair that I supplied in my second response executes
with no errors.
If, under SQLUnit 4.8 you can specify partial outputs, it appears that you are
still using the "id" attribute to indicate the position, but that this "id"
attribute now has no relation to the "id" attribute in the <param> tag, or the
parameter position within the stored procedure. In effect, you are
treating output parameters differently from input-only parameters.
I did replace the id=(1,4,5) in the test to (1,2,3) to reflect the
order of the outparams that are coming back (and not the parameter
position), and the test case executes with no failures.
Modifying the "id" attribute for the outparams isn't a problem for this
small test. However, with respect to all the SQLUnit tests I have
written, then this will be a problem. Up to this point, I have used
the "id" as the parameter position within the called statement.
-jh
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> I believe the JDBC specification uses positional parameters regardless of "in" or "out" status, in the same manner.
Good point, thanks for pointing it out, I will change the outparam ids generated to use the JDBC parameter id.
-sujit
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have moved the tail end of this thread to "Outparam matching problems" since it probably makes it more visible and better for tracking.
-sujit
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2005-06-14
The sqlunit-4.8.jar file in the binary distribution seems to be missing the sqlunit.dtd file? I'm having problems that are fixed if I put the file in there by hand.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I checked this in sqlunit build.xml. Sqlunit distribution packages are created with
ant package
which produces a jar without the dtd. On the other hand,
ant install
explicitly copies sqlunit.dtd from doc dir to build dir.
This issue can be easily resolved by making package target depend on install target and delete the following two lines from package target:
<jar jarfile="${dist.dir}/sqlunit-${rel.ver}.jar"
basedir="${build.dir}" />
<move file="${dist.dir}/sqlunit-${rel.ver}.jar" todir="${dist.dir}/sqlunit-${rel.ver}/lib" />
If there is an interest in this solution I can submit the patch.
Regards
Ivan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for catching the problem, and the description of the fix was detailed enough so I did it without any problems. Its in CVS now:
Checking in build.xml;
/cvsroot/sqlunit/sqlunit/build.xml,v <-- build.xml
new revision: 1.108; previous revision: 1.107
done
I also verified at my end that making the change described by Ivan does indeed result in a sqlunit.jar file with the sqlunit.dtd file in it.
-sujit
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Here are the release notes:
Release notes for SQLUnit version 4.7
Bugs fixed in this release
--------------------------
- Partial functionality was not working for either resultset or row. Bug pointed out by Meghanath and Chris Snow.
- assertion "outparams-equal" changed to match on id instead of position, to make it similar in behavior to resultsets-equal. The feature was triggered by a problem matching partial outparams reported by Greg Vatman.
Changes in this release
-----------------------
- New JARs added to lib: commons-jexl-1.0.jar to support the ExpressionMatcher functionality, and commons-logging.jar to satisfy dependencies for commons-jexl-1.0.jar.
New Features in this release
----------------------------
- new result attribute echo, if set to true, will print the generated result. - new assertion "none" to do no matching and always report success, requested by Meghanath.
- new assertion "not-exception" to assert that the result is not an exception, requested by Meghanath.
- new XSLT based Transform tool to convert legacy XML into SQLUnit test files, based on a request from Meghanath.
- new ExpressionMatcher that can be used to match using conditional expressions written in JEXL, based on a feature request from Craeg Strong. JEXL syntax is explained at their page:
http://jakarta.apache.org/commons/jexl/reference/index.html
- DOCTYPE SYSTEM id no longer needs to point to a relative or absolute file path to reference the sqlunit.dtd file. It is now supplied as part of the JAR file. Simply specifying sqlunit.dtd in the system id will reference the sqlunit.dtd file as a resource from the JAR file. This was based on a requirement from Greg Vatman to point to the sqlunit.dtd file in a web environment. Note that this change is backward compatible with the existing way of specifying it using file:/relative path or file:/absolute path too, so existing tests dont need to change.
Please let me know if you see any problems.
Thanks
Sujit
Hi Sujit,
One problem that I am seeing is a new error when I run my test suite.
Here is a sample error:
net.sourceforge.sqlunit.SQLUnitException: outparam[2].id(10) out of bounds
Any ideas?
Here is a sample stored procedure and SQLUnit tests that will expose this problem
create procedure SQLUnit_TestMultipleOutputParams
(
@param1 integer,
@param2 integer,
@param3 integer output,
@param4 integer output
)
as
begin
set nocount on -- Don't return number of rows affected
--
-- Declare Variables
--
declare @ReturnCode integer -- Return code
--
-- Initialize variables
--
set @ReturnCode = 0
--
-- Provide a default value if NULL
--
set @param3 = 5 + isnull(@param1, 0)
set @param4 = 10 + isnull(@param2, 0)
ExitProc:
return (@ReturnCode)
set nocount off
end
go
<test name="TestSQLUnit_TestMultipleOutputParams_1: Test multiple output-only parameters; set output params to NULL ">
<call>
<stmt>
{? = call SQLUnit_TestMultipleOutputParams(?,?,?,?)}
</stmt>
<param id="1" type="INTEGER" inout="out" is-null="false" name="ReturnValue">${retval}</param>
<param id="2" type="INTEGER" inout="in" is-null="false" name="param1">5</param>
<param id="3" type="INTEGER" inout="in" is-null="false" name="param2">10</param>
<param id="4" type="INTEGER" inout="out" is-null="true" name="param3">NULL</param>
<param id="5" type="INTEGER" inout="out" is-null="true" name="param4">NULL</param>
</call>
<result>
<outparam id="1" type="INTEGER">0</outparam>
<outparam id="4" type="INTEGER">10</outparam>
<outparam id="5" type="INTEGER">20</outparam>
</result>
</test>
<test name="TestSQLUnit_TestMultipleOutputParams_2: Test multiple output-only parameters; set output params to non-NULL value">
<call>
<stmt>
{? = call SQLUnit_TestMultipleOutputParams(?,?,?,?)}
</stmt>
<param id="1" type="INTEGER" inout="out" is-null="false" name="ReturnValue">${retval}</param>
<param id="2" type="INTEGER" inout="in" is-null="false" name="param1">5</param>
<param id="3" type="INTEGER" inout="in" is-null="false" name="param2">10</param>
<param id="4" type="INTEGER" inout="out" is-null="false" name="param3">0</param>
<param id="5" type="INTEGER" inout="out" is-null="false" name="param4">0</param>
</call>
<result>
<outparam id="1" type="INTEGER">0</outparam>
<outparam id="4" type="INTEGER">10</outparam>
<outparam id="5" type="INTEGER">20</outparam>
</result>
</test>
<test name="TestSQLUnit_TestMultipleOutputParams_3: Test multiple inout parameters; set output params to NULL value">
<call>
<stmt>
{? = call SQLUnit_TestMultipleOutputParams(?,?,?,?)}
</stmt>
<param id="1" type="INTEGER" inout="out" is-null="false" name="ReturnValue">${retval}</param>
<param id="2" type="INTEGER" inout="in" is-null="false" name="param1">5</param>
<param id="3" type="INTEGER" inout="in" is-null="false" name="param2">10</param>
<param id="4" type="INTEGER" inout="inout" is-null="true" name="param3">NULL</param>
<param id="5" type="INTEGER" inout="inout" is-null="true" name="param4">NULL</param>
</call>
<result>
<outparam id="1" type="INTEGER">0</outparam>
<outparam id="4" type="INTEGER">10</outparam>
<outparam id="5" type="INTEGER">20</outparam>
</result>
</test>
<test name="TestSQLUnit_TestMultipleOutputParams_4: Test multiple inout parameters; set output params to non-NULL value">
<call>
<stmt>
{? = call SQLUnit_TestMultipleOutputParams(?,?,?,?)}
</stmt>
<param id="1" type="INTEGER" inout="out" is-null="false" name="ReturnValue">${retval}</param>
<param id="2" type="INTEGER" inout="in" is-null="false" name="param1">5</param>
<param id="3" type="INTEGER" inout="in" is-null="false" name="param2">10</param>
<param id="4" type="INTEGER" inout="inout" is-null="false" name="param3">0</param>
<param id="5" type="INTEGER" inout="inout" is-null="false" name="param4">0</param>
</call>
<result>
<outparam id="1" type="INTEGER">0</outparam>
<outparam id="4" type="INTEGER">10</outparam>
<outparam id="5" type="INTEGER">20</outparam>
</result>
</test>
Hi James,
This may be related to the fix I made to change the behavior of outparam-equals. I am looking at it, will post more info as I find it.
-sujit
Hi James,
I havent had a chance to run the sproc yet, since I dont have access to a Sybase database at the moment. BTW, if you could check to see what you are getting by replacing the <result>...</result> part of the tests with a <result echo="true" /> that would be very helpful too.
As to what the error message means:
outparam[2].id(10) out of bounds ==
A second outparam in the result (by position) has the id="10", and SQLUnit does not find 10 outparams returned from the sproc call, and hence cannot match.
However, your test does not have outparam id="10" anywhere, I thought it may be a bug where I pull the text value in instead (outparam id=4 is 10 in both tests), but I did a quick check, and the code does pass the id attribute correctly, so maybe I am missing something and need to look more closely.
This is indeed due to a change in SQLUnit 4.8, and I apologize for breaking existing functionality, but I see that you are using the id as a shorthand to indicate the position of the parameter. SQLUnit did not care about the ids so far, it matched only by position, but as of SQLUnit 4.8 it allows you to specify the outparams partially, so for example, you could specify the 2nd and 3rd inouts only if you did not care about the first out parameter and SQLUnit will only match the ones you specify. I need to match by id for this.
Not sure how much work it would be for you, and I apologize again if its a lot, but if you replace the id=(1,4,5) in your tests to (1,2,3) to reflect the outparams that are coming back, then your tests should run fine.
To specify details about the outparams, you could use the name attribute, which is currently unused and is likely to be so, since it was created for this very purpose.
But the (10) coming back in the error message is a bug, I will see why thats happening and let you know.
-sujit
Hi Sujit,
I apologize for the confusion. I should have been more explicit with my
responses.
My original response was with respect to another test I was running.
One that called a stored procedure that has 10 parameters. The second response
was a stored procedure/test pair that exposed the issue that I was seeing
(without having to send you my original stored procedure/test pair).
The error I receive with the stored procedure/test pair in my second response is:
net.sourceforge.sqlunit.SQLUnitException: outparam[2].id(4) out of bounds
So there should be no bug with respect to where you pull the text value
(at least as far as I know).
I used the id attribute, since it is required according to the SQLUnit
documentation online (see http://sqlunit.sourceforge.net/c460.html#AEN1575
for <param> and http://sqlunit.sourceforge.net/c460.html#AEN2162 for <outparam>).
Since the id attribute is one-based to follow the JDBC specification, I have
based all my id values on the position of the parameters, including the
output parameters. I believe the JDBC specification uses positional parameters
regardless of "in" or "out" status, in the same manner.
You indicated that "SQLUnit did not care about the ids so far", but that is not
clear within the documentation. In fact, as recently as SQLUnit 4.7
the stored procedure/test pair that I supplied in my second response executes
with no errors.
If, under SQLUnit 4.8 you can specify partial outputs, it appears that you are
still using the "id" attribute to indicate the position, but that this "id"
attribute now has no relation to the "id" attribute in the <param> tag, or the
parameter position within the stored procedure. In effect, you are
treating output parameters differently from input-only parameters.
I did replace the id=(1,4,5) in the test to (1,2,3) to reflect the
order of the outparams that are coming back (and not the parameter
position), and the test case executes with no failures.
Modifying the "id" attribute for the outparams isn't a problem for this
small test. However, with respect to all the SQLUnit tests I have
written, then this will be a problem. Up to this point, I have used
the "id" as the parameter position within the called statement.
-jh
Hi James,
> I believe the JDBC specification uses positional parameters regardless of "in" or "out" status, in the same manner.
Good point, thanks for pointing it out, I will change the outparam ids generated to use the JDBC parameter id.
-sujit
I have moved the tail end of this thread to "Outparam matching problems" since it probably makes it more visible and better for tracking.
-sujit
The sqlunit-4.8.jar file in the binary distribution seems to be missing the sqlunit.dtd file? I'm having problems that are fixed if I put the file in there by hand.
I can confirm this issue from the .GZ file that I just pulled down.
You can resolve this problem by rebuilding the projecting. i.e., issue the command
ant install
and that should ensure that sqlunit.dtd is in the new JAR that is built.
Hello,
I checked this in sqlunit build.xml. Sqlunit distribution packages are created with
ant package
which produces a jar without the dtd. On the other hand,
ant install
explicitly copies sqlunit.dtd from doc dir to build dir.
This issue can be easily resolved by making package target depend on install target and delete the following two lines from package target:
<jar jarfile="${dist.dir}/sqlunit-${rel.ver}.jar"
basedir="${build.dir}" />
<move file="${dist.dir}/sqlunit-${rel.ver}.jar" todir="${dist.dir}/sqlunit-${rel.ver}/lib" />
If there is an interest in this solution I can submit the patch.
Regards
Ivan
Hi Tim/James/Ivan,
Thanks for catching the problem, and the description of the fix was detailed enough so I did it without any problems. Its in CVS now:
Checking in build.xml;
/cvsroot/sqlunit/sqlunit/build.xml,v <-- build.xml
new revision: 1.108; previous revision: 1.107
done
I also verified at my end that making the change described by Ivan does indeed result in a sqlunit.jar file with the sqlunit.dtd file in it.
-sujit