The `InsertOnDuplicateSetStep#set()` methods should declare FIREBIRD_3_0
support as with `InsertOnConflictDoUpdateStep#doUpdate()`. Support this
in `InsertQueryImpl` by emulating it using `MERGE`.
Add MEMSQL and SQLSERVER2012 to OrderedAggregateFunction, as this API is
referenced by e.g. DSL#percentileCont() which states support for both of
these dialects.
Users keep running into issues when they don't see why their
org.jooq.util classes from the code generator cannot be found. This
change helps them better find the new package qualification of types in
the jOOQ-meta and jOOQ-codegen modules.
Adds the methods Context#sql(long), sql(float), and sql(double). These
are used by the default converters in DefaultBinding for better
performance.
Note that there is no sql(boolean), since "true" and "false" are
expected to be treated as keywords and as such respect the keyword
rendering style.
This commit makes `NumberFormatException`s less likely to happen in
`Convert.ConvertAll#from(Object)` by first attempting to parse the
string representation of the value using `Ints#tryParse()` or
`Longs#tryParse()` (as appropriate). If that fails the conversion will
still try to use `BigDecimal(String)`, as that also allows parsing
numbers with fractions and / or exponent.
Note that this change required moving `tryParseInt()` and
`tryParseLong()` from `Tools` to the new public classes `Ints` and
`Longs` which have the license header from the corresponding
Guava sources, where the methods were copied from.
When rendering Integer values (e.g. represented by Val objects) the
`DefaultIntegerBinding` can be optimized to use `RenderContext#sql(int)`
rather than `RenderContext#sql(String)`, as the latter requires to first
call `Integer#toString()`.
Improves the rendering of SQL relying on the keyword placeholders in
string templates as in e.g. "{substring}({0} {from} {1} {for} {2})",
where {substring} and {from} denote keywords.
The rendering is improved by changing `KeywordImpl` to lazily render the
keywords in the UPPER, LOWER, and PASCAL styles.
In some cases, it may make sense to support reversing the invocation
order for some listener lists, e.g. for VisitListener (in this
commit), depending on whether we're calling a [action]Start() or an
[action]End() event.
In some cases, it may make sense to support reversing the invocation
order for some listener lists, e.g. for TransactionListener (in this
commit), depending on whether we're calling a [action]Start() or an
[action]End() event.
In some cases, it may make sense to support reversing the invocation
order for some listener lists, e.g. for RecordListener (in this
commit), depending on whether we're calling a [action]Start() or an
[action]End() event.
In some cases, it may make sense to support reversing the invocation order for some listener lists, e.g. for ExecuteListener (in this commit), depending on whether we're calling a [action]Start() or an [action]End() event.
