Bump jdbi3.version from 3.51.0 to 3.52.0

[dependabot]

Bumps jdbi3.version from 3.51.0 to 3.52.0.
Updates org.jdbi:jdbi3-core from 3.51.0 to 3.52.0

Release notes

Sourced from org.jdbi:jdbi3-core's releases.

3.52.0

Changes to java.time related classes

JDBC 4.2 added full support to map java.time classes onto SQL types in 2014. This release of Jdbi switches from mapping these objects onto "classic" (java.sql.Date, Time, Timestamp) to using the JDBC 4.2 API (PreparedStatement#setObject and ResultSet#getObject).

These changes should not be visible for any database, except if you were brave enough to map types with time zones or offsets (ZonedDateTime and OffsetDateTime) onto SQL types that have no timezone (TIMESTAMP or DATETIME). This affects databases that do not support the TIMESTAMP WITH TIMEZONE data type. IAW MySQL.

If you use MySQL with Jdbi and map any of these data types, you are already losing the zone/offset information. Now you actually get an error (which is the correct behavior of the driver!) unless you load the new MysqlPlugin which restores the mapping.

If your application relies on legacy mappings, you can also use the new @Legacy annotation to force the old behavior. See the documentation at https://jdbi.org/ for details.

Other changes and bug fixes

• Add MySQL specific module (jdbi3-mysql) and plugin (MysqlPlugin).
• Add new SqlExceptionHandler hook to handle database exceptions thrown during statement execution
• Add option to not attach sensitive binding data with OpenTelemetry (#2941, thanks @​gmellemstrand !)
• Add configuration for Jackson serialization of types with custom polymorphic handling (#2915)
• Update to JUnit 6.0.3
• Retire Apache Derby integration (#2866)
• Run test suite against Spring Framework 7 (#2919)
• Add OraclePlugin that sets untyped null argument to Types.NULL for Oracle compatibility (#1003)
• Support INOUT parameters for stored procedure Call statements (#1606)
• Map java.time types according to JDBC 4.2 spec (using setObject) (#988)
• Add @Legacy annotation to restore old timestamp mapping behavior
• Make @BindMethodsList work with the String template engine (fixes #2917, reported by @​agavrilov76, fixed by @​JScodesconcise)

Changelog

Sourced from org.jdbi:jdbi3-core's changelog.

3.52.0

Changes to java.time related classes

JDBC 4.2 added full support to map java.time classes onto SQL types in 2014. This release of Jdbi switches from mapping these objects onto "classic" (java.sql.Date, Time, Timestamp) to using the JDBC 4.2 API (PreparedStatement#setObject and ResultSet#getObject).

These changes should not be visible for any database, except if you were brave enough to map types with time zones or offsets (ZonedDateTime and OffsetDateTime) onto SQL types that have no timezone (TIMESTAMP or DATETIME). This affects databases that do not support the TIMESTAMP WITH TIMEZONE data type. IAW MySQL.

If you use MySQL with Jdbi and map any of these data types, you are already losing the zone/offset information. Now you actually get an error (which is the correct behavior of the driver!) unless you load the new MysqlPlugin which restores the mapping.

If your application relies on legacy mappings, you can also use the new @Legacy annotation to force the old behavior. See the documentation at https://jdbi.org/ for details.

• Add MySQL specific module (jdbi3-mysql) and plugin (MysqlPlugin).
• Add new SqlExceptionHandler hook to handle database exceptions thrown during statement execution
• Add option to not attach sensitive binding data with OpenTelemetry (#2941, thanks @​gmellemstrand !)
• Add configuration for Jackson serialization of types with custom polymorphic handling (#2915)
• Update to JUnit 6.0.2
• Retire Apache Derby integration (#2866)
• Run test suite against Spring Framework 7 (#2919)
• Add OraclePlugin that sets untyped null argument to Types.NULL for Oracle compatibility (#1003)
• Support INOUT parameters for stored procedure Call statements (#1606)
• Map java.time types according to JDBC 4.2 spec (using setObject) (#988)
• Add @Legacy annotation to restore old timestamp mapping behavior
• Make @BindMethodsList work with the String template engine (fixes #2917, reported by @​agavrilov76, fixed by @​JScodeconcise)

Commits

• c1e4d67 [maven-release-plugin] prepare release v3.52.0
• 37f0f28 add missing license header
• 6a6910d update maven to current version
• e55f9fd prepare release
• 4700b36 Merge pull request #2950 from hgschmie/dep-updates
• 672c6c9 Merge pull request #2949 from JScodesconcise/bug-2917
• 5be9028 Fix StringTemplate bindMethodsList name generation
• ce7d6ec update native plugin to 0.11.5 (from 0.11.4)
• 9aa6e24 Dependency updates
• 5430416 Merge pull request #2946 from hgschmie/mysql-module
• Additional commits viewable in compare view

Updates org.jdbi:jdbi3-sqlobject from 3.51.0 to 3.52.0

Release notes

Sourced from org.jdbi:jdbi3-sqlobject's releases.

3.52.0

Changes to java.time related classes

JDBC 4.2 added full support to map java.time classes onto SQL types in 2014. This release of Jdbi switches from mapping these objects onto "classic" (java.sql.Date, Time, Timestamp) to using the JDBC 4.2 API (PreparedStatement#setObject and ResultSet#getObject).

These changes should not be visible for any database, except if you were brave enough to map types with time zones or offsets (ZonedDateTime and OffsetDateTime) onto SQL types that have no timezone (TIMESTAMP or DATETIME). This affects databases that do not support the TIMESTAMP WITH TIMEZONE data type. IAW MySQL.

If you use MySQL with Jdbi and map any of these data types, you are already losing the zone/offset information. Now you actually get an error (which is the correct behavior of the driver!) unless you load the new MysqlPlugin which restores the mapping.

If your application relies on legacy mappings, you can also use the new @Legacy annotation to force the old behavior. See the documentation at https://jdbi.org/ for details.

Other changes and bug fixes

• Add MySQL specific module (jdbi3-mysql) and plugin (MysqlPlugin).
• Add new SqlExceptionHandler hook to handle database exceptions thrown during statement execution
• Add option to not attach sensitive binding data with OpenTelemetry (#2941, thanks @​gmellemstrand !)
• Add configuration for Jackson serialization of types with custom polymorphic handling (#2915)
• Update to JUnit 6.0.3
• Retire Apache Derby integration (#2866)
• Run test suite against Spring Framework 7 (#2919)
• Add OraclePlugin that sets untyped null argument to Types.NULL for Oracle compatibility (#1003)
• Support INOUT parameters for stored procedure Call statements (#1606)
• Map java.time types according to JDBC 4.2 spec (using setObject) (#988)
• Add @Legacy annotation to restore old timestamp mapping behavior
• Make @BindMethodsList work with the String template engine (fixes #2917, reported by @​agavrilov76, fixed by @​JScodesconcise)

Changelog

Sourced from org.jdbi:jdbi3-sqlobject's changelog.

3.52.0

Changes to java.time related classes

JDBC 4.2 added full support to map java.time classes onto SQL types in 2014. This release of Jdbi switches from mapping these objects onto "classic" (java.sql.Date, Time, Timestamp) to using the JDBC 4.2 API (PreparedStatement#setObject and ResultSet#getObject).

These changes should not be visible for any database, except if you were brave enough to map types with time zones or offsets (ZonedDateTime and OffsetDateTime) onto SQL types that have no timezone (TIMESTAMP or DATETIME). This affects databases that do not support the TIMESTAMP WITH TIMEZONE data type. IAW MySQL.

If you use MySQL with Jdbi and map any of these data types, you are already losing the zone/offset information. Now you actually get an error (which is the correct behavior of the driver!) unless you load the new MysqlPlugin which restores the mapping.

If your application relies on legacy mappings, you can also use the new @Legacy annotation to force the old behavior. See the documentation at https://jdbi.org/ for details.

• Add MySQL specific module (jdbi3-mysql) and plugin (MysqlPlugin).
• Add new SqlExceptionHandler hook to handle database exceptions thrown during statement execution
• Add option to not attach sensitive binding data with OpenTelemetry (#2941, thanks @​gmellemstrand !)
• Add configuration for Jackson serialization of types with custom polymorphic handling (#2915)
• Update to JUnit 6.0.2
• Retire Apache Derby integration (#2866)
• Run test suite against Spring Framework 7 (#2919)
• Add OraclePlugin that sets untyped null argument to Types.NULL for Oracle compatibility (#1003)
• Support INOUT parameters for stored procedure Call statements (#1606)
• Map java.time types according to JDBC 4.2 spec (using setObject) (#988)
• Add @Legacy annotation to restore old timestamp mapping behavior
• Make @BindMethodsList work with the String template engine (fixes #2917, reported by @​agavrilov76, fixed by @​JScodeconcise)

Commits

• c1e4d67 [maven-release-plugin] prepare release v3.52.0
• 37f0f28 add missing license header
• 6a6910d update maven to current version
• e55f9fd prepare release
• 4700b36 Merge pull request #2950 from hgschmie/dep-updates
• 672c6c9 Merge pull request #2949 from JScodesconcise/bug-2917
• 5be9028 Fix StringTemplate bindMethodsList name generation
• ce7d6ec update native plugin to 0.11.5 (from 0.11.4)
• 9aa6e24 Dependency updates
• 5430416 Merge pull request #2946 from hgschmie/mysql-module
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)