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(javax.sql.DataSource ds,
java.lang.String sql)
Convenient constructor with DataSource and SQL string.
|
| Modifier and Type | Method and Description |
|---|---|
protected abstract T |
mapRow(java.sql.ResultSet rs,
int rowNum,
java.lang.Object[] parameters,
java.util.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(java.lang.Object[] parameters,
java.util.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(javax.sql.DataSource ds,
java.lang.String sql)
ds - DataSource to use to get connectionssql - SQL to runprotected RowMapper<T> newRowMapper(java.lang.Object[] parameters, java.util.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(java.sql.ResultSet rs, int rowNum, java.lang.Object[] parameters, java.util.Map<?,?> context) throws java.sql.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.java.sql.SQLException - if there's an error extracting data.
Subclasses can simply not catch SQLExceptions, relying on the
framework to clean up.