root
/
spring-framework
mirror of https://github.com/spring-projects/spring-framework.git
1
0
Fork 0
Code Issues Actions Packages Projects Releases Wiki Activity

Update spring.jdbc.getParameterType.ignore note for 6.1.2 

See gh-25679
This commit is contained in:
Juergen Hoeller 2024-07-10 15:15:26 +02:00
parent a0f5c16627
commit 300f4585be
1 changed files with 19 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

29
framework-docs/modules/ROOT/pages/data-access/jdbc/advanced.adoc
View File

@ -211,19 +211,28 @@ the JDBC driver. If the count is not available, the JDBC driver returns a value
==== ====
In such a scenario, with automatic setting of values on an underlying `PreparedStatement`, In such a scenario, with automatic setting of values on an underlying `PreparedStatement`,
the corresponding JDBC type for each value needs to be derived from the given Java type. the corresponding JDBC type for each value needs to be derived from the given Java type.
While this usually works well, there is a potential for issues (for example, with Map-contained While this usually works well, there is a potential for issues (for example, with
`null` values). Spring, by default, calls `ParameterMetaData.getParameterType` in such a Map-contained `null` values). Spring, by default, calls `ParameterMetaData.getParameterType`
case, which can be expensive with your JDBC driver. You should use a recent driver in such a case, which can be expensive with your JDBC driver. You should use a recent driver
version and consider setting the `spring.jdbc.getParameterType.ignore` property to `true` version and consider setting the `spring.jdbc.getParameterType.ignore` property to `true`
(as a JVM system property or via the (as a JVM system property or via the
xref:appendix.adoc#appendix-spring-properties[`SpringProperties`] mechanism) if you encounter xref:appendix.adoc#appendix-spring-properties[`SpringProperties`] mechanism)
a performance issue (as reported on Oracle 12c, JBoss, and PostgreSQL). if you encounter a specific performance issue for your application.
Alternatively, you might consider specifying the corresponding JDBC types explicitly, As of 6.1.2, Spring bypasses the default `getParameterType` resolution on PostgreSQL and
either through a `BatchPreparedStatementSetter` (as shown earlier), through an explicit type MS SQL Server. This is a common optimization to avoid further roundtrips to the DBMS just
array given to a `List<Object[]>` based call, through `registerSqlType` calls on a for parameter type resolution which is known to make a very significant difference on
custom `MapSqlParameterSource` instance, or through a `BeanPropertySqlParameterSource` PostgreSQL and MS SQL Server specifically, in particular for batch operations. If you
that derives the SQL type from the Java-declared property type even for a null value. happen to see a side effect e.g. when setting a byte array to null without specific type
indication, you may explicitly set the `spring.jdbc.getParameterType.ignore=false` flag
as a system property (see above) to restore full `getParameterType` resolution.
Alternatively, you could consider specifying the corresponding JDBC types explicitly,
either through a `BatchPreparedStatementSetter` (as shown earlier), through an explicit
type array given to a `List<Object[]>` based call, through `registerSqlType` calls on a
custom `MapSqlParameterSource` instance, through a `BeanPropertySqlParameterSource`
that derives the SQL type from the Java-declared property type even for a null value, or
through providing individual `SqlParameterValue` instances instead of plain null values.
==== ====