Prior to this commit, JdbcClient's BatchSpec bound parameters to a
"current" batch entry and separated consecutive entries via add(). That
style was error-prone, since a missing add() still compiled but
silently merged parameters into a single entry. It also did not lend
itself to providing batch parameters dynamically — for example, from an
existing collection of domain objects.
To address that, this commit replaces the chaining style with
self-contained batch entries. BatchSpec now provides entry(...) methods
that define a single entry — via a Consumer<BatchEntry> callback, a
List of positional parameters, or a Map of named parameters — as well
as entries(...) methods that define one entry per parameter object.
Such calls can be freely combined within the same batch.
The new BatchEntry type exposes only the singular param(...) and
paramSource(...) methods. The add() method as well as the param(...),
params(...), and paramSource(...) methods have been removed from
BatchSpec.
Closes gh-37341
`batchArgs[0]` in `NamedParameterJdbcTemplate` and `indexedBatch[0]` in
`DefaultJdbcClient` are already set by
`pscf::newPreparedStatementCreator`, so it is unnecessary to set them
again via `BatchPreparedStatementSetter::setValues`.
Closes gh-37308
Signed-off-by: Yanming Zhou <zhouyanming@gmail.com>
Introduce a fluent batch() operation on JdbcClient.StatementSpec that
accumulates several sets of parameters - bound as positional or named
parameters in the same fashion as a single update, separated by add() -
and executes them as a single JDBC batch through update(). Batch updates
previously required dropping down to (NamedParameter)JdbcTemplate.
Closes gh-37216
Co-authored-by: Jiří Krokviak <j.krokviak@gmail.com>
Signed-off-by: Jiří Krokviak <j.krokviak@gmail.com>
Signed-off-by: Yanming Zhou <zhouyanming@gmail.com>
This commit extends LazyConnectionInvocationHandler to cache early
calls to:
- setClientInfo(String, String)
- setNetworkTimeout(Executor, int)
These methods now defer physical connection acquisition until Statement
creation, consistent with existing lazy behavior for autoCommit,
readOnly, transactionIsolation, catalog, and schema.
We also accept and lazily cache calls to setNetworkTimeout() even when
the provided Executor is null. Since some JDBC driver implementations
completely ignore the Executor parameter (or fall back to a default
executor), we cannot meaningfully validate or handle a null Executor
before the physical connection is obtained.
getClientInfo() and getClientInfo(String) remain non-lazy (triggering
immediate connection fetch), because they are read operations whose
values cannot be reliably cached due to driver defaults, pooled
connection remnants, or external session modifications.
setClientInfo(Properties) also remains non-lazy. The reason is that JDBC
driver implementations are inconsistent. Some treat it as overwrite,
others as append/merge. To guarantee behavior identical to non-lazy
execution across all drivers, we choose not to cache or replay it,
avoiding any risk of semantic mismatch.
See gh-37258
Closes gh-37261
Signed-off-by: Chengang Guan <guanchengang@qq.com>
When a column was declared via usingColumns() and also listed in
usingGeneratedKeyColumns(), TableMetaDataContext.reconcileColumnsToUse
accepted the declared list as-is: the generated key column was rendered
into the INSERT statement and counted against the parameter values,
even though the database is expected to generate its value.
Such an overlap is a configuration error, so it is now rejected at
compile time with an InvalidDataAccessApiUsageException naming the
offending columns in their declared spelling, consistent with the
existing validation in AbstractJdbcInsert.compile(). Matching is
case-insensitive, mirroring the normalization used for auto-discovered
columns; the auto-discovery path itself is unchanged and continues to
exclude generated key columns silently.
The tests cover the rejection, its message, a case-insensitive variant,
and the untouched non-overlapping declared path.
Closes gh-37014
Signed-off-by: junhyeong9812 <pickjog@gmail.com>
Every error code setter in SQLErrorCodes sorts its array with
StringUtils.sortStringArray, and CustomSQLErrorCodesTranslation does
the same, because SQLErrorCodeSQLExceptionTranslator looks the codes
up with Arrays.binarySearch. setDuplicateKeyCodes was the only setter
that stored the supplied array as-is.
With an unsorted list of duplicate key codes, the binary search finds
or misses a code depending on where the values happen to sit: for
codes it misses, the translator silently falls through to the SQLState
fallback and reports a DataIntegrityViolationException, or fails to
translate at all, instead of the configured DuplicateKeyException. The
default sql-error-codes.xml is not affected since its lists are
already sorted; the mismatch surfaces for custom configurations, for
example codes of different digit lengths listed in numeric order.
setDuplicateKeyCodes now sorts the array like all sibling setters. The
new test covers an unsorted custom list whose codes previously hit or
missed depending on their position.
Closes gh-37235
Signed-off-by: junhyeong9812 <pickjog@gmail.com>
This commit introduces additional unit tests for CallMetaDataContext's
function return parameter matching in reconcileParameters(), verifying
that the declared return parameter is correctly resolved regardless of
whether it is declared before or after an additional OUT parameter.
See gh-37206
CallMetaDataContext.reconcileParameters() keys the map of declared
parameters by lowerCase(provider.parameterNameToUse(name)), but the
branch that matches the return parameter reported by the database
metadata did not apply the same rule. It looked up the function return
name as declared (original case) and fell back to the first declared
OUT parameter name with a plain toLowerCase(), without the provider
transformation that strips the '@' prefix on SQL Server and Sybase.
The first lookup therefore always missed on Oracle, so the fallback
silently used whichever OUT parameter was declared first. Declaring an
additional OUT parameter before the return parameter of a function made
that parameter double as the return slot: the declared return parameter
was dropped from the call parameters, the wrong parameter was bound at
position 1, and executeFunction() returned the value of the other out
parameter. On SQL Server, a procedure compiled with withReturnValue()
and an '@'-prefixed OUT parameter declared before the return parameter
failed with InvalidDataAccessApiUsageException because neither lookup
could find the declared parameter.
The return parameter branch now looks up the metadata-derived name
first and normalizes both the function return name and the first OUT
parameter fallback with the same rule as the declared parameter map.
Tests cover both declaration orders for an Oracle function and for a
SQL Server procedure with a return value.
Closes gh-37206
Signed-off-by: junhyeong9812 <pickjog@gmail.com>
Although this commit also changes the visibility of some test methods
to package-private, the remainder of that task will be addressed in
conjunction with gh-36496.
Closes gh-36495
This PR optimizes the performance of NamedParameterUtils#buildValueArray by deferring the call to findParameter(declaredParams, paramName, i).
Changes: In the original implementation, findParameter was called for every parameter in the loop, regardless of whether the paramValue retrieved from paramSource was already an instance of SqlParameterValue.
Since findParameter involves iterating through the declaredParams list (or performing lookups), skipping this call when paramValue instanceof SqlParameterValue is true reduces unnecessary CPU cycles and memory access, especially for queries with a large number of parameters or long declaredParams lists.
Signed-off-by: qwding <761945125@qq.com>
Yanming Zhou
Sam Brannen
Juergen Hoeller
guanchengang
김준형
junhyeong9812
Brian Clozel
Manu Sridharan
Philippe Marschall
Sébastien Deleuze
Chris
qwding
jher235