Add DSL#unique(Select) which represents the standard SQL "UNIQUE"
constraint. Since no of the supported dialects natively support UNIQUE,
the constraint is always emulated as a NOT EXISTS predicate (and NOT
UNIQUE is emulated as a corresponding EXISTS predicate). See the
following example:
NOT EXISTS (
SELECT NULL
FROM (SELECT 1 a, 2 b UNION ALL SELECT 1 a, 2 b) t
WHERE (a, b) IS NOT NULL
GROUP BY a, b
HAVING count(*) > 1
)
In jOOQ 3.x, the DSL API is mostly mutable. For set operations, this means that a query x cannot appear on both sides of the set operation, e.g. x.union(x) is not possible.
As of version 3.24.0 SQLite natively supports INSERT's ON CONFLICT
clause, which can thus also be used by jOOQ.
Note: SQLite doesn't support combining DEFAULT VALUES with ON CONFLICT.
And since SQLite does not support the DEFAULT keyword in INSERT the
DEFAULT VALUES clause cannot be emulated.
The current distinction is confusing, and if redundant uniqueness information is present, then Hibernate ignores the @UniqueConstraint name. Hence, we will only generate the @UniqueConstraint annotation
Add <includeExpression> and <excludeExpression> as well as
<includeTypes> and <excludeTypes> to <forcedType>. The generator will
warn about usage conflicting with the legacy <expression>,
<expressions>, and <types> elements.
InsertOnConflictConditionStep now extends InsertReturningStep rather
than InsertFinalStep and is now also the type returned by the methods
declared in InsertOnConflictWhereStep.
[#8522] Emulate the PL/SQL BOOLEAN type in SQL functions in Oracle 12c
[#3607] Allow for emitting common table expression declarations to RenderContext
Historically, SQL casts were ignored if jOOQ's Field<T> type was of the same type T as the cast type. This makes sense for some internals, but not in the public API. When a user wants to cast an expression, this should always produce a SQL cast.
Using the new <onError/> (which accepts the values FAIL (default), LOG,
and SILENT) the generator's behavior on an encountered exceptions can be
controlled.
MySQL doesn't support the useful WHERE clause on ON DUPLICATE KEY UPDATE like PostgreSQL does on ON CONFLICT. But it can easily be emulated using CASE if users do not rely on the effective update counts.
H2 1.4.198 changed array syntax incompatibly to align the syntax with PostgreSQL, HSQLDB, and the SQL standard. The old syntax (which conflicts with row value expression) is no longer really supported.
H2 1.4.198 changed array syntax incompatibly to align the syntax with PostgreSQL, HSQLDB, and the SQL standard. The old syntax (which conflicts with row value expression) is no longer really supported.
H2 breaks backwards compatibility in 1.4.198 and supports row value expressions at the price of desupporting the "old" vendor specific array syntax. This means we can now remove some H2 specific logic and implement standard row value expression syntax also for H2
Some SQLDataTypes are "synthetic" aliases of other types, and as such could not yet be used as forcedType names because they were not recognised, despite what the manual says.
