SQL Server has a bug when it comes to bulk inserting DECIMAL with scale
values (see https://github.com/microsoft/mssql-jdbc/issues/1021 for
details). As a workaround jOOQ will in this scenario explicitly cast the
corresponding column values in the bulk set.
Add `MYSQL` to `@Support` annotation on
`InsertOnDuplicateStep#onConflictOnConstraint()`, since this is
consistent with `InsertQuery#onConflictOnConstraint()` and supported for
the `doNothing()` step.
The Javadoc deprecation notice for methods deprecated with
jOOQ/jOOQ#4763 now references the `DSL` methods `noCondition()`,
`trueCondition()`, and `falseCondition()`.
`DSL#currentTimestamp()` and `DSL#now()` have been overloaded with a
method declaring a `Field<Integer>` parameter, representing the
precision for the timestamp function. Many dialects support this.
Also the parser can now parse expressions like `NOW(6)`.
The "defaultNameCase" -> RenderNameCase mapping in DDLDatabase was
incorrect and caused problems.
Also explicitly declares a local variable as `final` for Java 6
compatibility.
Extracted new class DDLDatabaseInitializer from DDLDatabase. This new
class is in package `org.jooq.extensions.ddl` of Maven module
`jOOQ-extensions`.
As a consequence also renamed the configuration data keys
"org.jooq.meta.extensions.ddl.ignore-storage-clauses" and
"org.jooq.meta.extensions.ddl.parse-for-ddldatabase" to
"org.jooq.extensions.ddl.ignore-storage-clauses" and
"org.jooq.extensions.ddl.parse-for-ddldatabase" respectively.
Having the `DefaultRecordMapper` internally also use
`Configuration#recordMapperProvider()` is important when the user needs
control over how nested POJOs get mapped.
- Got rid of a few more SQL templating cases
- Removed some unnecessary nullSafe() calls
- Use nullSafeDataType() where appropriate
- Fix regression in OracleDSL#matches(Field, String, int)
SQL Server has a bug when it comes to bulk inserting DECIMAL with scale
values (see https://github.com/microsoft/mssql-jdbc/issues/1021 for
details). As a workaround jOOQ will in this scenario explicitly cast the
first column value in the bulk set.
The jOOQ 3.12 Open Source Edition will continue to support Java 8. The only things we gain from the JDK 11 dependency is:
- Updated logic for reflection when mapping into proxied default methods (that stuff has changed completely in JDK 9). This is a regression, which we can live with. The workaround is to write a custom
- Explicit dependency on the JDK 9 API, for which we provide a Java 8 compatible alternative via reactive streams anyway.
- JDBC 4.3 compatibility (mostly sharding). We currently don't use that yet.
We're not even using internally, outside of a few integration tests. So, we'll postpone the JDK 11 *requirement* (while supporting it nonetheless) to a later release, e.g. 3.13. We'll observe market share shifts. Currently Java 11's market share is a bit of a disappointment, so making it a requirement might be premature.
