Class DefaultQueryParameterApplicator

java.lang.Object
de.calamanari.adl.sql.DefaultQueryParameterApplicator
All Implemented Interfaces:
QueryParameterApplicator, Serializable

public class DefaultQueryParameterApplicator extends Object implements QueryParameterApplicator
The 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 Details

    • getInstance

      public static final DefaultQueryParameterApplicator getInstance()
      Returns:
      the only instance of this creator
    • apply

      public void apply(PreparedStatement stmt, QueryParameter parameter, int parameterIndex) throws SQLException
      Description copied from interface: QueryParameterApplicator
      Sets 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:
      apply in interface QueryParameterApplicator
      Parameters:
      stmt -
      parameter -
      parameterIndex -
      Throws:
      SQLException - if the set operation on the prepared statement failed
    • applyUnsafe

      public void applyUnsafe(StringBuilder sb, QueryParameter parameter, int parameterIndex)
      Description copied from interface: QueryParameterApplicator
      Appends 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 custom ArgValueFormatters.
      Specified by:
      applyUnsafe in interface QueryParameterApplicator
      Parameters:
      sb -
      parameter -
      parameterIndex -