Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support named parameters in CallableStatementCreator implementation [SPR-4406] #9084

Closed
spring-projects-issues opened this issue Jan 29, 2008 · 4 comments
Labels
has: votes-jira Issues migrated from JIRA with more than 10 votes at the time of import in: data Issues in data modules (jdbc, orm, oxm, tx) status: declined A suggestion or change that we don't feel we should currently apply type: enhancement A general enhancement

Comments

@spring-projects-issues
Copy link
Collaborator

spring-projects-issues commented Jan 29, 2008

Mike Calmus opened SPR-4406 and commented

Named parameters have been added for some operations, but the execution of a CallableStatement does not support named parameters.

The following code block from CallableStatementFactory.CallableStatementCreatorImpl would be affected or need to be extended:

int sqlColIndx = 1;
for (int i = 0; i < declaredParameters.size(); i++) {
	SqlParameter declaredParameter = (SqlParameter) declaredParameters.get(i);
	if (!declaredParameter.isResultsParameter()) {
		// So, it's a call parameter - part of the call string.
		// Get the value - it may still be null.
		Object inValue = this.inParameters.get(declaredParameter.getName());
		if (declaredParameter instanceof ResultSetSupportingSqlParameter) {
			// It's an output parameter: SqlReturnResultSet parameters already excluded.
			// It need not (but may be) supplied by the caller.
			if (declaredParameter instanceof SqlOutParameter) {
				if (declaredParameter.getTypeName() != null) {
					cs.registerOutParameter(sqlColIndx, declaredParameter.getSqlType(), declaredParameter.getTypeName());
				}
				else {
					if (declaredParameter.getScale() != null) {
						cs.registerOutParameter(sqlColIndx, declaredParameter.getSqlType(), declaredParameter.getScale().intValue());
					}
					else {
						cs.registerOutParameter(sqlColIndx, declaredParameter.getSqlType());
					}
				}
				if ((declaredParameter).isInputValueProvided() || inValue != null) {
					StatementCreatorUtils.setParameterValue(csToUse, sqlColIndx, declaredParameter, inValue);
				}
			}
		}
		else {
			// It's an input parameter- must be supplied by the caller.
			if (!this.inParameters.containsKey(declaredParameter.getName())) {
				throw new InvalidDataAccessApiUsageException(
						"Required input parameter '" + declaredParameter.getName() + "' is missing");
			}
			StatementCreatorUtils.setParameterValue(csToUse, sqlColIndx, declaredParameter, inValue);
		}
		sqlColIndx++;
	}
}

Issue Links:

10 votes, 8 watchers

@spring-projects-issues
Copy link
Collaborator Author

Thomas Risberg commented

Not sure what the benefit would be. The recommended stored procedure classes are StoredProcedure and SImpleJdbcCall. Both of those create the call string behind the scenes and wouldn't need to use named parameters. The CallableStatementFactory is a helper class and parsing of a named parameter call statement can be done beforehand using NamedParameterUtils.parseSqlStatementIntoString(String s) method.

@spring-projects-issues
Copy link
Collaborator Author

Mike Calmus commented

Using the StoredProcedure class as-is requires users of a stored procedure to know the exact position and sequence of each parameter and prevents the database developer from making changes to the procedure's parameters (such as adding new optional parameters or re-ordering parameters) without also changing all code making calls to it.

@spring-projects-issues
Copy link
Collaborator Author

spring-projects-issues commented Mar 25, 2008

Thomas Risberg commented

OK, now I understand what you are looking for. This is related to #8193. Both issues require using named parameters for setting and registering parameters which involves some major changes internally. We will try to address this for Spring 3.0.

@jhoeller
Copy link
Contributor

Closing this old ticket along with #30207.

@jhoeller jhoeller added the status: declined A suggestion or change that we don't feel we should currently apply label Nov 24, 2023
@jhoeller jhoeller removed this from the General Backlog milestone Nov 24, 2023
@bclozel bclozel closed this as not planned Won't fix, can't repro, duplicate, stale Nov 24, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
has: votes-jira Issues migrated from JIRA with more than 10 votes at the time of import in: data Issues in data modules (jdbc, orm, oxm, tx) status: declined A suggestion or change that we don't feel we should currently apply type: enhancement A general enhancement
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants