public abstract class MappingSqlQueryWithParameters<T> extends SqlQuery<T>
Such manual mapping is usually preferable to "automatic" mapping using reflection, which can become complex in non-trivial cases. For example, the present class allows different objects to be used for different rows (for example, if a subclass is indicated). It allows computed fields to be set. And there's no need for ResultSet columns to have the same names as bean properties. The Pareto Principle in action: going the extra mile to automate the extraction process makes the framework much more complex and delivers little real benefit.
Subclasses can be constructed providing SQL, parameter types and a DataSource. SQL will often vary between subclasses.
MappingSqlQuery, 
SqlQuery| Modifier and Type | Class and Description | 
|---|---|
protected class  | 
MappingSqlQueryWithParameters.RowMapperImpl
Implementation of RowMapper that calls the enclosing
 class's  
mapRow method for each row. | 
logger| Constructor and Description | 
|---|
MappingSqlQueryWithParameters()
Constructor to allow use as a JavaBean 
 | 
MappingSqlQueryWithParameters(DataSource ds,
                             String sql)
Convenient constructor with DataSource and SQL string. 
 | 
| Modifier and Type | Method and Description | 
|---|---|
protected abstract T | 
mapRow(ResultSet rs,
      int rowNum,
      Object[] parameters,
      Map<?,?> context)
Subclasses must implement this method to convert each row
 of the ResultSet into an object of the result type. 
 | 
protected RowMapper<T> | 
newRowMapper(Object[] parameters,
            Map<?,?> context)
Implementation of protected abstract method. 
 | 
execute, execute, execute, execute, execute, execute, execute, execute, execute, execute, execute, execute, executeByNamedParam, executeByNamedParam, findObject, findObject, findObject, findObject, findObject, findObject, findObject, findObject, findObject, findObject, findObjectByNamedParam, findObjectByNamedParam, getRowsExpected, setRowsExpectedcompileInternal, getParsedSql, newPreparedStatementCreator, newPreparedStatementCreator, newPreparedStatementSetter, onCompileInternalafterPropertiesSet, allowsUnusedParameters, checkCompiled, compile, declareParameter, getDeclaredParameters, getGeneratedKeysColumnNames, getJdbcTemplate, getResultSetType, getSql, isCompiled, isReturnGeneratedKeys, isUpdatableResults, setDataSource, setFetchSize, setGeneratedKeysColumnNames, setJdbcTemplate, setMaxRows, setParameters, setQueryTimeout, setResultSetType, setReturnGeneratedKeys, setSql, setTypes, setUpdatableResults, supportsLobParameters, validateNamedParameters, validateParameterspublic MappingSqlQueryWithParameters()
public MappingSqlQueryWithParameters(DataSource ds, String sql)
ds - DataSource to use to get connectionssql - SQL to runprotected RowMapper<T> newRowMapper(Object[] parameters, Map<?,?> context)
newRowMapper in class SqlQuery<T>parameters - the parameters to the execute() method,
 in case subclass is interested; may be null if there
 were no parameters.context - contextual information passed to the mapRow
 callback method. The JDBC operation itself doesn't rely on this parameter,
 but it can be useful for creating the objects of the result list.SqlQuery.execute(java.lang.Object[], java.util.Map<?, ?>)protected abstract T mapRow(ResultSet rs, int rowNum, Object[] parameters, Map<?,?> context) throws SQLException
rs - ResultSet we're working throughrowNum - row number (from 0) we're up toparameters - to the query (passed to the execute() method).
 Subclasses are rarely interested in these.
 It can be null if there are no parameters.context - passed to the execute() method.
 It can be null if no contextual information is need.SQLException - if there's an error extracting data.
 Subclasses can simply not catch SQLExceptions, relying on the
 framework to clean up.