in that thread, James said...
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
To which Sujit commented...
> 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 looked at the code where the outparams were being set and when generated they did inherit the id of the param element in the input, so what you did is correct.
I have changed the matching logic in the assertion to look up the id of the parameter to be matched using a small internal hashmap. Can you see if this works? I will build a test for this but I wanted to check it in since theres a lag between my checking it in and it becoming available. Here are the files that have changed:
Checking in src/net/sourceforge/sqlunit/Assertions.java;
/cvsroot/sqlunit/sqlunit/src/net/sourceforge/sqlunit/Assertions.java,v <-- Assertions.java
new revision: 1.20; previous revision: 1.19
done
Checking in src/net/sourceforge/sqlunit/SQLUnit.java;
/cvsroot/sqlunit/sqlunit/src/net/sourceforge/sqlunit/SQLUnit.java,v <-- SQLUnit.java
new revision: 1.52; previous revision: 1.51
done
Checking in src/net/sourceforge/sqlunit/handlers/ParamHandler.java;
/cvsroot/sqlunit/sqlunit/src/net/sourceforge/sqlunit/handlers/ParamHandler.java,v <-- ParamHandler.java
new revision: 1.10; previous revision: 1.9
done
Thanks for pointing out the bug before it became widespread :-).
-sujit
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Good, thanks for the feedback. I guess I must have checked in Param.java earlier so I must have missed it in the commit message. Thanks for catching that.
-sujit
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Was: SQLUnit 4.8 has been released
in that thread, James said...
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
To which Sujit commented...
> 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
Hi James,
I looked at the code where the outparams were being set and when generated they did inherit the id of the param element in the input, so what you did is correct.
I have changed the matching logic in the assertion to look up the id of the parameter to be matched using a small internal hashmap. Can you see if this works? I will build a test for this but I wanted to check it in since theres a lag between my checking it in and it becoming available. Here are the files that have changed:
Checking in src/net/sourceforge/sqlunit/Assertions.java;
/cvsroot/sqlunit/sqlunit/src/net/sourceforge/sqlunit/Assertions.java,v <-- Assertions.java
new revision: 1.20; previous revision: 1.19
done
Checking in src/net/sourceforge/sqlunit/SQLUnit.java;
/cvsroot/sqlunit/sqlunit/src/net/sourceforge/sqlunit/SQLUnit.java,v <-- SQLUnit.java
new revision: 1.52; previous revision: 1.51
done
Checking in src/net/sourceforge/sqlunit/handlers/ParamHandler.java;
/cvsroot/sqlunit/sqlunit/src/net/sourceforge/sqlunit/handlers/ParamHandler.java,v <-- ParamHandler.java
new revision: 1.10; previous revision: 1.9
done
Thanks for pointing out the bug before it became widespread :-).
-sujit
Hi Sujit,
I downloaded the modfied files and attempted to rebuild, but received an error while compiling ParamHandler.java (v1.10).
It turns out that Param.java (v1.6) is required for this to compile cleanly. Once I downloaded Param.java, the project rebuilt without errors.
I then re-ran my test case that exposed this issue, which executed without failures.
-jh
Hi James,
Good, thanks for the feedback. I guess I must have checked in Param.java earlier so I must have missed it in the commit message. Thanks for catching that.
-sujit