Whether calls to store(), insert(), update(), and delete() that are called on an UpdatableRecord
that is created from a POJO (e.g. in a DAO) should return all Record values to the POJO, including
IDENTITY values, and if is active, also other values.

isRenderOrderByRownumberForEmulatedPagination

Whether an additional ORDER BY rn clause should be rendered on emulated paginated queries.

Older databases did not support OFFSET .. FETCH pagination, so jOOQ emulates it using derived
tables and ROWNUM (Oracle 11g and older) or ROW_NUMBER() (e.g. DB2,
SQL Server, etc.) filtering. While these subqueries are ordered, the ordering is not
guaranteed to be stable in the outer most queries. It may be stable (and e.g. in Oracle,
it mostly is, if queries are not parallel, or joined to other queries, etc.), so the excess
ORDER BY clause may add some additional performance overhead. This setting forces
jOOQ to not generate the additional ORDER BY clause.

isReturnRecordToPojo

Whether calls to store(), insert(), update(), and delete() that are called on an UpdatableRecord
that is created from a POJO (e.g. in a DAO) should return all Record values to the POJO, including
IDENTITY values, and if is active, also other values.

isEmulateOnDuplicateKeyUpdateOnPrimaryKeyOnly

[#6462] Use only the primary key to emulate MySQL's INSERT .. ON DUPLICATE KEY UPDATE statement. In MySQL, the statement considers all unique keys for duplicates to apply an update rather than an insert. Earlier versions of jOOQ considered only the PRIMARY KEY. This flag can be turned on to maintain backwards compatibility.