jOOQ should internally try to avoid using SQL templating. As a result
most implementation classes representing SQL built-in functions which
before inherited from `AbstractFunction` now directly extend
`AbstractField` instead and directly render the SQL rather than
returning a `Field` object to be rendered.
The current implementation is checking if a given InvocationOrder setting is the DEFAULT. We should better check the inverse, if it is REVERSE and act accordingly. That way, both DEFAULT and null have the DEFAULT behaviour.
Parser doesn't correctly parse identifiers that can conflict with keywords. For example, when parsing TRIM(TRAILING.C) where TRAILING is a table reference, we parse it as a keyword and don't check if it is really just a qualified identifier. Whenever there's a . following a keyword, we'll treat the token as a non-keyword.
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.
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.
For the benefit of performance Tools#renderAndBind() now no longer uses
Integer#parseInt() when deciding whether a placeholder is a keyword or
an index of a bind value.
Also AbstractQuery#bind(String, Object) and DefaultBinding#parse(Class,
String) no longer rely on Integer#parseInt() or Long#parseLong().
The new methods in Tools are based on the Guava method
Longs#tryParse(String, int).
For SQLite the Java 8 time types Offset[Date|DateTime|Time] and Instant
are now supported. SQLite basically supports date and time data with
time zones as input. Returned values are however always in Zulu / UTC
time, as with some other dialects.
In SQLite the binding of [Local|Offset][Date][Time] literals didn't
always work correctly when the value specified fractional seconds. This
was because the corresponding DSL method would return a DateOrTime
instance rather than a simple Tools#field() constructed instance. This
commit fixes that.
SQL Server's LOG() function defines the parameters in reverse order from
the SQL standard (see
https://docs.microsoft.com/sql/t-sql/functions/log-transact-sql?view=sql-server-2017).
Also, instead of a dedicated LN() function the natural logarithm is
calculated by omitting the second parameter (representing the base). The
same applies to SQL Data Warehouse.
Again reverting change in DSL#log(Number, int) to use Tools#field() over
DSL#val().
SQLITE should normally be compared against the dialect family.
Also replace some occurrences of `context.configuration().dialect()`
with `context.dialect()`.
Adds an overload DSL#log(Field, Field) which is also used by the parser,
as the base can for multiple dialects both be a float literal or an
arbitrary expression.
