This documentation is for the unreleased development version of jOOQ. Click on the above version links to get this documentation for a supported version of jOOQ.
Applies to ❌ Open Source Edition ✅ Express Edition ✅ Professional Edition ✅ Enterprise Edition
jOOQ's code generator may decide that a column is readonly, in case of which using it in various DML statements may subtly change. The following Settings govern this behaviour:
Settings.readonlyInsert: Inclusion in an INSERT statement, or in the
INSERTclause of a MERGE statement.
Settings.readonlyUpdate: Inclusion in an UPDATE statement, or in the
UPDATEclause of a MERGE statement.
Settings.readonlyTableRecordInsert: Inclusion in a TableRecord.insert() operation, or the
INSERTpart or execution of TableRecord.store() or UpdatableRecord.merge(). If this is deactivated, Settings.readonlyInsert still applies
Settings.readonlyUpdatableRecordUpdate: Inclusion in a UpdatableRecord.update() operation, or the
UPDATEpart or execution of TableRecord.store() or UpdatableRecord.merge(). If this is deactivated, Settings.readonlyUpdate still applies
Each one of these flags is of type
org.jooq.conf.WriteIfReadonly with these permitted states:
WRITE: Write to the column as if it weren't readonly. This effectively turns off the feature.
IGNORE: Ignore the column in a relevant statement. This is the default.
THROW: Throw an exception if the column is included in a relevant DML statement.
The default behaviour
IGNORE is particularly useful when loading POJO data into
org.jooq.UpdatableRecord and storing it, while ignoring
IDENTITY columns, computed columns, synthetic columns (such as the synthetic ROWIDs), and more:
// If BOOK.ID is an auto-generated identity, we don't want to load NULL values into the record. create.newRecord(BOOK, bookPojo);
Do you have any feedback about this page? We'd love to hear it!