Prior to this commit, if an SQLException was thrown while retrieving
column metadata from the database, SimpleJdbcInsert would generate an
INSERT statement that was syntactically valid but missing columns,
which could lead to data silently missing in the database (for nullable
columns).
This commit fixes this by clearing all collected column metadata if an
SQLException is thrown while processing the metadata. The result is
that an InvalidDataAccessApiUsageException will be thrown later while
generating the INSERT statement. The exception message now contains an
additional hint to make use of SimpleJdbcInsert#usingColumns() in order
to ensure that all required columns are included in the generated
INSERT statement.
SimpleJdbcCall can also encounter an SQLException while retrieving
column metadata for a stored procedure/function, but an exception is
not thrown since a later invocation of the stored procedure/function
will likely fail anyway due to missing arguments. Consequently, this
commit only improves the warning level log message by including a hint
to make use of SimpleJdbcCall#addDeclaredParameter().
Closes gh-26486
This commit reverts some changes done in 2d5f9723fa
in order to fix JdbcOperations.queryForObject and
JdbcOperations.queryForList.
It is not possible to provide a vararg variant in Kotlin
for now due to a signature clash, but that will probably
make sense in Spring Framework 6 timeframe along to array
based variant removal for both Java and Kotlin.
Closes gh-26312
Prior to this commit, some tests would belong to the PERFORMANCE
`TestGroup`, while they were not testing for performance but rather
performing functional tests that involve long running operations or
timeouts.
This commit moves those tests to the LONG_RUNNING `TestGroup`.
See gh-24830
Includes deprecation of JdbcUtils.extractDatabaseMetaData(DataSource, String) in favor of the now generified version of extractDatabaseMetaData(DataSource, DatabaseMetaDataCallback).
Closes gh-25681
Closes gh-25686
MVC data class processor constructs target instance even in case of binding failure, as long as the corresponding method parameter is not marked as optional.
Closes gh-24372
- The compiler is configured to retain compatibility with Kotlin 1.3.
- Explicit API mode is not yet enabled but could be in the future.
- Some exceptions thrown by Kotlin have changed to NullPointerException,
see https://youtrack.jetbrains.com/issue/KT-22275 for more details.
Closes gh-24171
Prior to this commit the BeanPropertyRowMapper used
String.substring and String.toLowerCase to parse the
field names. This would generate more String than needed.
Instead one could iterate over the internal char[] of the
String and use the Character methods instead. This reduces
the String creation.
Closes gh-25301
- The compiler is configured to retain compatibility with Kotlin 1.3.
- Explicit API mode is not yet enabled but could be in the future.
- A workaround for Gradle build is required for now, see
https://youtrack.jetbrains.com/issue/KT-39610 for more details.
- Some exceptions thrown by Kotlin have changed to NullPointerException,
see https://youtrack.jetbrains.com/issue/KT-22275 for more details.
Closes gh-24171
Prior to this commit, the JDBC KeyHolder API only supported keys of
type Number. However, a generated key can be a UUID or something else,
and developers shouldn't have to go manually through complex
collections to access it.
This commit adds a new getKeyAs(Class<T> keyType) method to the
KeyHolder API that allows the user to specify the key type.
Closes gh-24655
Hi guys,
We're facing an issue in our application when we try to call a procedure in Informix database,
our app uses standard JDBC (spring-jdbc and com.ibm.informix.jdbc.4.50.3) without Hibernate
to connect to the database
Issue:
When we trying to execute any procedure call in our Informix database there is no data returned.
Diagnostic:
It points to the Java class called CallMetaDataProviderFactory in spring-jdbc project.
Taking a look of this class there is no explicit support for Informix procedure calls, so I added "Informix Dynamic Server" to the
list of supported databases and now I can execute procedures call without issues.
Basically I added the line "Informix Dynamic Server" to the list called "supportedDatabaseProductsForProcedures"
of CallMetaDataProviderFactory class in my local environment and it worked as expected.
I really appreciate any feedback/suggestion for this approach due we would like to continue using the framework
normally in our development without losing updates using a workaround in our end.
Many thanks in advance.
Prior to this commit, the Spring Framework build would partially use the
dependency management plugin to import and enforce BOMs.
This commit applies the dependency management plugin to all Java
projects and regroups all version management declaration in the root
`build.gradle` file (versions and exclusions).
Some versions are overridden in specific modules for
backwards-compatibility reasons or extended support.
This commit also adds the Gradle versions plugin that checks for
dependency upgrades in artifact repositories and produces a report; you
can use the following:
./gradlew dependencyUpdates
This commit reorganizes tasks and scripts in the build to only apply
them where they're needed. We're considering here 3 "types" of projects
in our build:
* the root project, handling documentation, publishing, etc
* framework modules (a project that's published as a spring artifact)
* internal modules, such as the BOM, our coroutines support and our
integration-tests
With this change, we're strealining the project configuration for all
spring modules and only applying plugins when needed (typically our
kotlin support).
See gh-23282
This commit removes the JUnit 4 dependency from all modules except
spring-test which provides explicit JUnit 4 support.
This commit also includes the following.
- migration from JUnit 4 assertions to JUnit Jupiter assertions in all
Kotlin tests
- migration from JUnit 4 assumptions in Spring's TestGroup support to
JUnit Jupiter assumptions, based on org.opentest4j.TestAbortedException
- introduction of a new TestGroups utility class than can be used from
existing JUnit 4 tests in the spring-test module in order to perform
assumptions using JUnit 4's Assume class
See gh-23451
Update `ResourceDatabasePopulator` and `ScriptUtils` so that more than
one comment prefix can be used when processing SQL scripts. This
feature is particularly useful when dealing with scripts provided by
Quartz since they often use a mix `--` and `#`.
Closes gh-23289
This commit migrates to the MockitoJUnitRunner where sensible, which
will later allow for an easier migration to Mockito's extension for
JUnit Jupiter.
In addition, this commit deletes unnecessary stubbing for various mocks
and polishes test fixture setup in various test classes.
Organize test imports to expand all '.*' static imports into
fully qualified imports.
This update will allow us to use additional checkstyle rules in
the future, and will also help if we migrate fully to AssertJ.
* Add limited checkstyles to test code
Add a limited set of checkstyle rules to the test codebase to improve
code consistency.
* Fix checksyle violations in test code
* Organize imports to fix checkstyle for test code
* Migrate to assertThatExceptionOfType
Migrate aware from ExpectedException rules to AssertJ exception
assertions. Also include a checkstyle rules to ensure that the
the ExpectedException is not accidentally used in the future.
See gh-22894
Carsten Dimmek
Juergen Hoeller
Yanming Zhou
Sam Brannen
Sébastien Deleuze
alexscari
Сергей Цыпанов
Brian Clozel
Johnny Lim
Marten Deinum
eXsio
Juergen Hoeller
Sam Brannen
Qimiao Chen
Hyunjin Choi
wilrosco
hyeonisism
perceptron8
Kwon Young Jae
康智冬
Phillip Webb
Brian Clozel
Sebastien Deleuze
Stephane Nicoll
zhuzhuman978
chrunchyjesus