resultSetsForStatement mutiple definitions

[gbonk]

AbstractParameterResultSetHandler redundantly defines some parameters that AbstractResultSetHandler has already defined.  This is messing something up.  If I remove the redundant parameters from AbstractParameterResultSetHandler and add calls to the proper parameter from the child it all works great.

Can I/We clean this up so there isn't any confusion?

[gbonk]

Maybe I just don't understand how this is supposed to work.  I can't find any examples on using a Prepared statement with named parameters. Additionally we're using the Spring JDBC libs to help out which might be part of the problem. 

I have not been able to find any examples on how to do this NOT VIA the prepareGlobalResultSet()

My Query is like "SELECT rndup_ind FROM SZSL_KEY_ITM_BUCKET_ASGN WHERE itm_nbr = :itemNumber"

I have a result set....

PreparedStatementResultSetHandler handler = mockConn.getPreparedStatementResultSetHandler();

MockResultSet rs = handler.createResultSet();

rs.addColumn("rndup_ind");
rs.addRow(new Object[] { 24 });

I have a paramter list...

List parameterList = new ArrayList();
parameterList.add("itemNumber");

And I put it all together...

handler.prepareResultSet( "SELECT rndup_ind", rs, parameterList );

Which all results in a null result set.  Anywhere I can get a more detailed example on how to use the parameter list?

[Alwin Ibba]

JDBC PreparedStatements do not support named parameters. Mockrunner is based on plain JDBC. Besides that you are using it wrong. It makes no sense to put the parameter name or index in the parameter list for the prepare. You have to prepare the parameter value.

List parameterList = new ArrayList();
parameterList.add("xyz");

If the tested code prepares a statement "SELECT rndup_ind" and sets the expected parameter at the expected index (in this case the first parameter)

statement.setString(1, "xyz");

Mockrunner will return the prepared ResultSet.

Please have a look at the tests, e.g. MockPreparedStatementTest.testPrepareResultSet() and please read the JavaDoc descriptions of the ResultSetHandlers.

As mentioned PreparedStatements do not support named parameters. You have to figure out how the Spring NamedParameterJdbcTemplate implements this feature (I think by keeping the names and indices consistent internally, then you can use it). Mockrunner does not support Spring directly.

Kind regards,

Alwin

[gbonk]

Ah, that's a good point.  When one works with ORM so long that one forgets.  From what I've read, JDK 1.4 implements the JDBC 3.0 standard which says it has named parameters for callable statements.  I guess support is spotty.

Anyways...  After more fiddling and testing I'm guessing that there is some incompatability between Spring JDBC and Mockrunner.  As I remember the same is true for Hibernate as well. 

Does anyone know of any workarounds or patches to help mockrunner work with Spring or Hibernate?

[gbonk]

I've solved my problem.  Turns out Spring isn't doing anything too fancy that mockrunner can't handle.  Here are the details of "my mistake".  I found that when my test class only had one test in it worked fine.  Classes with multiple tests failed. 

I discovered that that because of Spring injection, spring is holding onto the first MockDatasource I created either in a constructor or SetUp.  Therefore when I added additional MockResultSets in subsequent test methods they were not available to spring because they were different instances.  I found if I move all of my result sets to the same area of instantiating the MockDatasource, and only do it once, then everything works.

Thanks.