I have attached a patch for DBUTILS-50 which requests OUT parameters for stored procedures. My approach was to add execute() methods to QueryRunner which will use a CallableStatement to run the SQL. If any of the parameters passed are instances of OutParameter (a new class), the parameter is registered as an OUT parameter with the CallableStatement and the value is available from the OutParameter instance after the call has completed. INOUT parameters are also supported by setting a value on the OutParameter instance. There are flavors of execute() for procedures returning result sets and procedures that return update counts.
For example supposed procedure my_proc takes four parameters; IN, OUT, INOUT, IN. The following example code would apply: QueryRunner runner = ... OutParameter<Integer> in = new OutParameter<>(Types.INTEGER, Integer.class); OutParameter<Integer> inout = new OutParameter<>(Types.VARCHAR, String.class, "input value"); runner.execute("{call my_proc(?,?,?,?)}", "value1", in, inout, 42); Integer inReturn = in.getValue(); String inoutReturn = inout.getValue(); I thought that this approach would keep to the principle of shielding the library users from the gory details of JDBC while keeping an interface consistent with the current code. Unfortunately we bend a little on the idea of keeping the user from needing to create helper objects, but something had to give. This way allows the user to interleave IN, OUT and INOUT parameters in the same set of arguments to the method keeping the method signature sane and familiar. I'd appreciate any feedback. Thanks, Ray