tokenではなくvalue?
を表すため、これを行うことはできません。明らかに、一部のトークン (つまり、リテラル) は値を表しますが、これらの場合でも、値を表すリテラルではなく、値自体を直接表します。(これは設計の意図的な要素です。パラメーター化されたクエリの目的は、パラメーターが「漏れ」、単一の値以外のものとして解釈されるのを防ぐことであるためです。)?
編集して追加:私が働いている場所では、JDBC をラップしてトランザクションなどを処理するカスタム フレームワークがあるため、通常PreparedStatement
は直接処理する必要はありません。そのフレームワークには、次のようなメソッドがあります。
public <T> Iterator<T> executeQuery(ConverterFromResultSetToT<T> converter,
String query, Map<String, Object> params)
{
// . . . modify query, replacing any instances of $!{paramKey} with the
// corresponding value from params -- this allows arbitrary SQL code
// to be injected, in the rare cases that that's necessary
// . . . modify query, replacing any instances of ${paramKey} with '?' and
// adding the corresponding value from params to an array -- we use
// this much more often
// . . . create PreparedStatement with the resulting query
// . . . set parameters of PreparedStatement from aforemented array
// . . . run PreparedStatement; wrap result in an Iterator<T>; and return
}
しかし、これをたくさん行うことが予想される場合にのみ、そのようなことをお勧めします. 私たちはそのフレームワークに多大な労力を注ぎました。これは信じられないほど便利ですが、大量のコードでもあります。
ドキュメントが何を暗示しているかにかかわらず、 を作成するコストはPreparedStatement
それほど高くないことに注意してください。PreparedStatement
実際に同じクエリを何度も実行していない限り、毎回再作成しても大したことではありません。そのため、独自のコードを作成する意思がある限り、ドロップイン演算子の組み込みサポートは実際には必要ありません。