Class DefaultQueryParameterApplicator
- All Implemented Interfaces:
QueryParameterApplicator, Serializable
DefaultQueryParameterApplicator exclusively supports the DefaultAdlSqlType as base types, means the types themselves or any type
that returns a DefaultAdlSqlType as its base type. Thus, it should be suitable for the regular types and most custom types.
By replacing the applicator, implementors get full control over the process how values from a QueryParameter get included in the sql resp. how the
processing works to set the parameters on a prepared statement.
- Author:
- Karl Eilebrecht
- See Also:
-
Method Summary
Modifier and TypeMethodDescriptionvoidapply(PreparedStatement stmt, QueryParameter parameter, int parameterIndex) Sets the value of the given parameter on the statement at the given index.voidapplyUnsafe(StringBuilder sb, QueryParameter parameter, int parameterIndex) Appends the value of the given parameter to an SQL script.static final DefaultQueryParameterApplicator
-
Method Details
-
getInstance
- Returns:
- the only instance of this creator
-
apply
public void apply(PreparedStatement stmt, QueryParameter parameter, int parameterIndex) throws SQLException Description copied from interface:QueryParameterApplicatorSets the value of the given parameter on the statement at the given index.This is the preferred (safe) method to process the parameters of an SQL-statement without the risk of SQL-injection.
- Specified by:
applyin interfaceQueryParameterApplicator- Parameters:
stmt-parameter-parameterIndex-- Throws:
SQLException- if the set operation on the prepared statement failed
-
applyUnsafe
Description copied from interface:QueryParameterApplicatorAppends the value of the given parameter to an SQL script.Warning! As the name of this method states, using this method to compose plain SQL-queries is inherently unsafe and highly discouraged.
Even with escaping, there is always a remaining risk of SQL-injection, users might somehow manage to enter text that slips through the string escaping by exploiting the behavior of a particular database/driver combination.Thus, it is strongly recommended to work with
PreparedStatements and their safe parameters.However, there may be reasons (e.g., no JDBC-driver available, comparison etc.) to use this method besides debugging and testing.
If so, please consider the following points:- The database user for querying should have minimal permissions, e.g., read-only.
- Can you avoid strings and fully rely on values of type integer, decimal, date etc.? If so, you are safe because this method intermediately converts values of these types to Java data types before composing the final string to be included in the query.
- Double-check the documentation of your database driver related to escaping.
- Related code should be subject to auditing. This is especially important for custom
AdlSqlTypes and customArgValueFormatters.
- Specified by:
applyUnsafein interfaceQueryParameterApplicator- Parameters:
sb-parameter-parameterIndex-
-