We have encountered an issue with parameter mapping in Spring JDBC when upgrading from Spring Boot 3.3.7 to 3.4.x. The behavior of the SimpleJdbcCall.execute method appears to have changed, resulting in improperly mapped parameters for stored procedure calls.

Code Example: Here is a minimal reproducible example:

java Copiar código Map params = new HashMap<>(); params.put("pin_fechanac", "08/12/1958");

final Map resultMap = execStoreProcedureNativeQuery( "pkg_calcular_edad.p_obtieneedad", params );

// Underlying implementation calls jdbcCall.execute(paramMap) Behavior in Spring Boot 3.3.7: The MapSqlParameterSource correctly maps the parameter as follows:

java Copiar código Map params = matchInParameterValuesWithCallParameters(parameterSource); Return: {PIN_FECHANAC=08/12/1958} Behavior in Spring Boot 3.4.x: The matchInParameterValuesWithCallParameters method now returns an empty map:

java Copiar código Map params = matchInParameterValuesWithCallParameters(parameterSource); Return: {}

In Spring Boot 3.4.x, the params map is empty, causing the stored procedure to receive no input parameters, whereas it worked as expected in 3.3.7.

Comment From: snicoll

Here is a minimal reproducible example:

Sorry that isn't one. Can you please move this code in text into a sample we can actually run? You can attach a zip to this issue with the sample project or push the code to a separate GitHub repository. Please include database information (or a docker compose file so that we can start it if necessary).

Comment From: gitcastilar

Hi Stephane,

I hope this email finds you well.

I am attaching a zipped Maven project related to the issue we’re addressing. For context, we are currently working with a production application on Oracle 11 and have plans to migrate to Oracle 19 by the end of 2025.

Additionally, I have included the stored procedure (SP) file in the resources directory of the attached project.

Please let me know if you need further information or clarification.

Best regards,

Andrés On Sunday, December 29, 2024 at 02:25:32 PM GMT-3, Stéphane Nicoll @.***> wrote:

Here is a minimal reproducible example:

Sorry that isn't one. Can you please move this code in text into a sample we can actually run? You can attach a zip to this issue with the sample project or push the code to a separate GitHub repository. Please include database information (or a docker compose file so that we can start it if necessary).

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

Comment From: snicoll

@gitcastilar the attachment in the email you sent was not processed by GitHub. FTR we don't need your project but a minimal sample that helps us reproducing the problem. Please come back to GitHub to attach it to this issue.

Comment From: gitcastilar

Hi there , I push all the code to reproduce the error in repo https://github.com/gitcastilar/spring34172issue
Regards

Comment From: facewise

@gitcastilar Hi. I've checked your issue and I found this problem is not related with Spring JDBC, but with Oracle JDBC driver compatibility. spring-boot-dependencies:3.3.7 declares the version of ojdbc11 as 21.9.0.0 but in 3.4.1, it turns 23.5.0.24.07. The new Oracle JDBC driver have made huge difference with the former and there are some changes when getting procedure columns which made your issue.

I recommend to explicitly specify the version of ojdbc11 as 21.9.0.0 in your pom.xml until you find the proper Oracle JDBC driver.

Comment From: gitcastilar

Hi,Thank you for your explanation regarding the issue. I understand that the problem is related to Oracle JDBC driver compatibility rather than Spring JDBC. I’ll explicitly specify the version of ojdbc11 as 21.9.0.0 in the pom.xml as recommended, and I’ll evaluate the changes in the new Oracle JDBC driver to find the most suitable version for our use case.Thanks again for your insights and guidance!Best regards,Andrés Enviado desde mi iPhoneEl

Comment From: jhoeller

Since this is dependent on the Oracle JDBC driver version, it seems there is nothing we do about it in spring-jdbc itself.