Spring Support Named Parameters in Stored Procedures

StoredProcedure binds by name or index depending on the method called.

The behavior after this PR is: - if #execute is called with an array then indexed bind variables are used - if #execute is called with a Map then named bind variables are used

This would be my expectation from reading the API.

The code has a couple of limitations: - there is unfortunately quite a bit of copy and paste - SqlValue and SqlTypeValue are not supported for named binds, they would need a #setValue or #setTypeValue method respectively that takes a parameter name rather than a parameter index

Existing users will get different behavior if they are calling the Map based method. This may break if: - the supplied parameter names do not match the parameter names of the procedure - if the driver does not support named parameters - they use SqlValue or SqlTypeValue

Closes gh-9084

Comment From: jhoeller

Since our entire JDBC infrastructure is based on indexed parameters, I do not see us supporting named bindings for stored procedures at the JDBC level, exactly for the reason that it leads to CallableStatement-specific duplication of quite a bit of code that can otherwise be reused with PreparedStatement-based code paths.

The execute(Map) support in StoredProcedure is meant to match local parameter names declared via declareParameter, possibly matching database-level parameter names but not necessarily so. Supporting database parameter names directly would allow for arbitrary ordering at the Java declaration level, I suppose, but this is arguably not a significant enough benefit to justify the processing complexity within Spring's JDBC support. Since the SQL types are important as well, a well-ordered sequence of declareParameter calls with name plus SQL type does seem quite appropriate in any case, aligned with the database-level declaration but explicitly declared with the same ordering at the Java level.

From that perspective, I'd rather close this PR. Thanks for your efforts, in any case!

Comment From: marschall

Fair enough should we then also close #9084 ?