Kiril Nugmanov opened SPR-12801 and commented
org.springframework.jdbc.core.simple.AbstractJdbcCall uses org.springframework.jdbc.core.metadata.CallMetaDataContext to generate JDBC statement.
In case of Oracle PL/SQL org.springframework.jdbc.core.metadata.CallMetaDataContext.createCallString can be changed to support default values by implementing following changes in constructing JDBC statement from:
{call some_package.some_procedure(?,?,?)}
to
{call some_package.some_procedure(p_parameter_1 => ?, p_parameter_2 => ?, p_parameter_3 =>?)}
Change can be implemented in 2 ways: * modify org.springframework.jdbc.core.metadata.CallMetaDataContext in case if DB is Oracle * introduce setter for callMetaDataContext in org.springframework.jdbc.core.simple.AbstractJdbcCall then users can introduce it's own modification of org.springframework.jdbc.core.metadata.CallMetaDataContext
Related to #9084, #8193
Affects: 4.1.5
Reference URL: https://github.com/spring-projects/spring-framework/pull/763
Issue Links: - #8193 StoredProcedure enhancement to allow parameters to be optional - #9084 Support named parameters in CallableStatementCreator implementation
1 votes, 4 watchers
Comment From: spring-projects-issues
Serge Shikov commented
The same for MS SQL please. At the moment (in spring 3.x versions) the same call syntax is used, with positional parameters only:
{call sp(?,?,?)}
and it prevents us from using parameters defined with default values.
Comment From: spring-projects-issues
Juergen Hoeller commented
We're considering this for 4.2 now. A pull request would be very much appreciated and would strongly increase the chances of this making it into 4.2 RC1!
Juergen
Comment From: spring-projects-issues
Kiril Nugmanov commented
Created pull #763
Comment From: spring-projects-issues
Stéphane Nicoll commented
I have a candidate fix based on your PR and a few modifications (see this commit). I am still not sure if swapping the context is the right move.
You may want to review the Spring Framework Code Style as it contains valuable resources regarding the code format and the structure of the commit message.
Comment From: spring-projects-issues
Kiril Nugmanov commented
Stéphane,
Can you explain why such swapping might be wrong?
Comment From: spring-projects-issues
Stéphane Nicoll commented
Hey, I am not saying it's wrong. I am just confused about the approach of generating always "?" or always a named parameter for a given SimpleJdbcCall instance. I am not sure I actually fully understand how it's being used in practice.
What's wrong with adding the parameter always?
Comment From: spring-projects-issues
Kiril Nugmanov commented
I think if you make named binding for Oracle/MS SQL as default for SimpleJdbcCall - previously working code might be broken. In existing code version there is no big deal how you name your parameters but in case of named parameters IS.
Comment From: spring-projects-issues
Stéphane Nicoll commented
Gotcha. What's the problem of adding a setNamedBinding() on the existing CallMetadataContext and handle everything from there? There are already other setters on this class so if the idea is to either do everything with ? or do everything with parameter name, the existing class should be able to support both.
Comment From: spring-projects-issues
Kiril Nugmanov commented
Adding setter in CallMetadataContext wont provide much flexibility. Moreover how you set namedBinding?
Current dependencies are following: AbstractJdbcCall<-CallMetaDataContext (CallMetaDataContext provided via constructor). So you need to create new instance of CallMetadataContext anyway and call setNamedBinding() on it.
Comment From: spring-projects-issues
Stéphane Nicoll commented
Fixed in a slightly different way, adding the notion of named binding in the current CallMetadataContext instead of relying on an extension.
A new 4.2.0.BUILD-SNAPSHOT should be available in the next couple of hours. Please give that a try!