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, setRowsExpected
compileInternal, getParsedSql, newPreparedStatementCreator, newPreparedStatementCreator, newPreparedStatementSetter, onCompileInternal
afterPropertiesSet, 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, validateParameters
public 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.