Readonly columns
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
INSERT
clause of a MERGE statement. -
Settings.readonlyUpdate: Inclusion in an UPDATE statement, or in the
UPDATE
clause of a MERGE statement. -
Settings.readonlyTableRecordInsert: Inclusion in a TableRecord.insert() operation, or the
INSERT
part 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
UPDATE
part 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);
Feedback
Do you have any feedback about this page? We'd love to hear it!