public Class UpdatableRecordImpl<R extends org.jooq.UpdatableRecord<R>>

Implements org.jooq.UpdatableRecord.children.

Doc from org.jooq.UpdatableRecord.children.

Get a table expression representing the children of this record, given a foreign key.

Annotations

@SuppressWarnings:unchecked

@Override

Implements org.jooq.UpdatableRecord.copy.

Doc from org.jooq.UpdatableRecord.copy.

Duplicate this record (in memory) and reset all fields from the primary key or main unique key, such that a subsequent call to store() will result in an INSERT statement.

Returns:R

A new record, distinct from this record.

Annotations

@SuppressWarnings:unchecked, rawtypes

@Override

Implements org.jooq.UpdatableRecord.delete.

Doc from org.jooq.UpdatableRecord.delete.

Deletes this record from the database, based on the value of the primary key or main unique key.

Optimistic locking

If a DELETE statement is executed and Settings#isExecuteWithOptimisticLocking() is set to true, then this record will first be compared with the latest state in the database. There are two modes of operation for optimistic locking:

• With VERSION and/or TIMESTAMP columns configured

  This is the preferred way of using optimistic locking in jOOQ. If this is an UpdatableRecord and if this record returns fields for either Table#getRecordVersion() or Table#getRecordTimestamp(), then these values are compared to the corresponding value in the database in the WHERE clause of the executed DELETE statement.

• Without any specific column configurations

  In order to compare this record with the latest state, the database record will be locked pessimistically using a SELECT … FOR UPDATE statement. Not all databases support the FOR UPDATE clause natively. Namely, the following databases will show slightly different behaviour:

  • SQLDialect#SQLSERVER: jOOQ will try to lock the database record using WITH (ROWLOCK, UPDLOCK) hints.
  • SQLDialect#SQLITE: No pessimistic locking is possible. Client code must assure that no race-conditions can occur between jOOQ's checking of database record state and the actual DELETE

  See SelectQuery#setForUpdate(boolean) for more details

Statement examples

The executed statement is

DELETE FROM [table]
WHERE [key fields = key values]
AND [version/timestamp fields = version/timestamp values]

This is in fact the same as calling delete(getTable().getPrimaryKey().getFieldsArray())

Returns:int

1 if the record was deleted from the database. 0 if deletion was not necessary.

Annotations

@Override

Implements org.jooq.UpdatableRecord.fetchChild.

Doc from org.jooq.UpdatableRecord.fetchChild.

Fetch a child record of this record, given a foreign key.

This returns a child record referencing this record through a given foreign key, as if fetching from children(ForeignKey).. If no child record was found, this returns null.

A separate roundtrip is created by this operation. It is often much better to include parent records using ordinary JOIN mechanisms in a single query, or using nested records, or the MULTISET or MULTISET_AGG operators, see https://www.jooq.org/doc/latest/manual/sql-building/column-expressions/nested-records/, or the https://www.jooq.org/doc/latest/manual/sql-building/column-expressions/multiset-value-constructor/.

Annotations

@Override

Implements org.jooq.UpdatableRecord.fetchChildren.

Doc from org.jooq.UpdatableRecord.fetchChildren.

Fetch child records of this record, given a foreign key.

This returns child records referencing this record through a given foreign key, as if fetching from children(ForeignKey).

A separate roundtrip is created by this operation. It is often much better to include parent records using ordinary JOIN mechanisms in a single query, or using nested records, or the MULTISET or MULTISET_AGG operators, see https://www.jooq.org/doc/latest/manual/sql-building/column-expressions/nested-records/, or the https://www.jooq.org/doc/latest/manual/sql-building/column-expressions/multiset-value-constructor/.

Annotations

@SuppressWarnings:unchecked

@Override

Implements org.jooq.UpdatableRecord.key.

Doc from org.jooq.UpdatableRecord.key.

A Record copy holding values for the Table#getPrimaryKey().

The returned record consists exactly of those fields as returned by the table's primary key: UniqueKey#getFields().

Generated subtypes may covariantly override this method to add more record type information. For instance, they may return Record1, Record2, ...

Annotations

@Override

Implements org.jooq.UpdatableRecord.merge.

Doc from org.jooq.UpdatableRecord.merge.

Store this record back to the database using a MERGE statement.

Unlike store(), the statement produced by this operation does not depend on whether the record has been previously fetched from the database or created afresh. It implements the semantics of an INSERT … ON DUPLICATE KEY UPDATE statement, which will update the row regardless of which (unique) key value is already present. See InsertOnDuplicateStep#onDuplicateKeyUpdate().

When optimistic locking is active for this record, then this operation will execute insert() or update() explicitly, depending on whether the lock values are present already in the record.

If you want to enforce statement execution, regardless if the values in this record were changed, you can explicitly set the changed flags for all values with changed(boolean) or for single values with changed(Field, boolean), prior to insertion.

This is the same as calling record.merge(record.fields())

Returns:int

1 if the record was merged to the database. 0 if merging was not necessary.

Annotations

@Override

Implements org.jooq.UpdatableRecord.merge.

Doc from org.jooq.UpdatableRecord.merge.

Store parts of this record to the database using a MERGE statement.

Returns:int

1 if the record was merged to the database. 0 if merging was not necessary.

Annotations

@Override

Implements org.jooq.UpdatableRecord.merge.

Doc from org.jooq.UpdatableRecord.merge.

Store parts of this record to the database using a MERGE statement.

Returns:int

1 if the record was merged to the database. 0 if merging was not necessary.

Annotations

@Override

Implements org.jooq.UpdatableRecord.refresh.

Doc from org.jooq.UpdatableRecord.refresh.

Refresh this record from the database.

A successful refresh results in the following:

• valuesRow() will have been restored to the respective values from the database
• original() will match this record
• changed() will be false

Refreshing can trigger any of the following actions:

• Executing a new SELECT statement, if this is an UpdatableRecord.
• Failing, otherwise

This is the same as calling record.refresh(record.fields())

Annotations

@Override

Implements org.jooq.UpdatableRecord.refresh.

Doc from org.jooq.UpdatableRecord.refresh.

Refresh parts of this record from the database.

A successful refresh results in the following:

• valuesRow() will have been restored to the respective values from the database
• original() will match this record
• changed() will be false

Refreshing can trigger any of the following actions:

• Executing a new SELECT statement, if this is an UpdatableRecord.
• Failing, otherwise

This is the same as calling record.refresh(record.fields())

Annotations

@Override

Implements org.jooq.UpdatableRecord.refresh.

Doc from org.jooq.UpdatableRecord.refresh.

Refresh parts of this record from the database.

A successful refresh results in the following:

• valuesRow() will have been restored to the respective values from the database
• original() will match this record
• changed() will be false

Refreshing can trigger any of the following actions:

• Executing a new SELECT statement, if this is an UpdatableRecord.
• Failing, otherwise

This is the same as calling record.refresh(record.fields())

Annotations

@Override

Implements org.jooq.UpdatableRecord.store.

Doc from org.jooq.UpdatableRecord.store.

Store this record back to the database.

Depending on the state of the primary key's value, an insert() or an update() statement is executed.

Statement type

• If this record was created by client code, an INSERT statement is executed
• If this record was loaded by jOOQ and the primary key value was changed, an INSERT statement is executed (unless Settings#isUpdatablePrimaryKeys() is set). jOOQ expects that primary key values will never change due to the principle of normalisation in RDBMS. So if client code changes primary key values, this is interpreted by jOOQ as client code wanting to duplicate this record.
• If this record was loaded by jOOQ, and the primary key value was not changed, an UPDATE statement is executed.

In either statement type, only those fields are inserted/updated, which had been explicitly set by client code, in order to allow for DEFAULT values to be applied by the underlying RDBMS. If no fields were modified, neither an UPDATE nor an INSERT will be executed.

Automatic value generation

Use insert() or update() to explicitly force either statement type.

• IDENTITY columns

  If there is an IDENTITY column defined on the record's underlying table (see Table#getIdentity()), then the auto-generated IDENTITY value is refreshed automatically on INSERT's. Refreshing is done using Statement#getGeneratedKeys(), where this is supported by the JDBC driver. See also InsertQuery#getReturnedRecord() for more details

• VERSION and TIMESTAMP columns

  jOOQ can auto-generate "version" and "timestamp" values that can be used for optimistic locking. If this is an UpdatableRecord and if this record returns fields for either Table#getRecordVersion() or Table#getRecordTimestamp(), then these values are set onto the INSERT or UPDATE statement being executed. On execution success, the generated values are set to this record. Use the code-generation configuration to specify naming patterns for auto-generated "version" and "timestamp" columns.

  Should you want to circumvent jOOQ-generated updates to these columns, you can render an INSERT or UPDATE statement manually using the various DSLContext#insertInto(Table), DSLContext#update(Table) methods.

Optimistic locking

If an UPDATE statement is executed and Settings#isExecuteWithOptimisticLocking() is set to true, then this record will first be compared with the latest state in the database. There are two modes of operation for optimistic locking:

• With VERSION and/or TIMESTAMP columns configured

  This is the preferred way of using optimistic locking in jOOQ. If this is an UpdatableRecord and if this record returns fields for either Table#getRecordVersion() or Table#getRecordTimestamp(), then these values are compared to the corresponding value in the database in the WHERE clause of the executed DELETE statement.

• Without any specific column configurations

  In order to compare this record with the latest state, the database record will be locked pessimistically using a SELECT … FOR UPDATE statement. Not all databases support the FOR UPDATE clause natively. Namely, the following databases will show slightly different behaviour:

  • SQLDialect#SQLSERVER: jOOQ will try to lock the database record using WITH (ROWLOCK, UPDLOCK) hints.
  • SQLDialect#SQLITE: No pessimistic locking is possible. Client code must assure that no race-conditions can occur between jOOQ's checking of database record state and the actual UPDATE

  See SelectQuery#setForUpdate(boolean) for more details

Statement examples

Possible statements are

• 
  INSERT INTO [table] ([modified fields, including keys])
  VALUES ([modified values, including keys])

• 
  UPDATE [table]
  SET [modified fields = modified values, excluding keys]
  WHERE [key fields = key values]
  AND [version/timestamp fields = version/timestamp values]

Statement execution enforcement

If you want to control statement re-execution, regardless if the values in this record were changed, you can explicitly set the changed flags for all values with changed(boolean) or for single values with changed(Field, boolean), prior to storing. Consider also setting the flags Settings#getUpdateUnchangedRecords() and/or Settings#isInsertUnchangedRecords() appropriately to control if the record should be "touched" without any changes (UPDATE) or inserted with default values (INSERT).

This is the same as calling record.store(record.fields())

Returns:int

1 if the record was stored to the database. 0 if storing was not necessary.

Annotations

@Override

Implements org.jooq.UpdatableRecord.store.

Doc from org.jooq.UpdatableRecord.store.

Store parts of this record to the database.

Returns:int

1 if the record was stored to the database. 0 if storing was not necessary.

Annotations

@Override

Implements org.jooq.UpdatableRecord.store.

Doc from org.jooq.UpdatableRecord.store.

Store parts of this record to the database.

Returns:int

1 if the record was stored to the database. 0 if storing was not necessary.

Annotations

@Override

Implements org.jooq.UpdatableRecord.update.

Doc from org.jooq.UpdatableRecord.update.

Store this record back to the database using an UPDATE statement.

This is the same as store(), except that an UPDATE statement (or no statement) will always be executed.

If you want to enforce statement execution, regardless if the values in this record were changed, you can explicitly set the changed flags for all values with changed(boolean) or for single values with changed(Field, boolean), prior to updating, or alternatively, use Settings#getUpdateUnchangedRecords().

This is the same as calling record.update(record.fields())

Returns:int

1 if the record was stored to the database. 0 if storing was not necessary.

Annotations

@Override

Implements org.jooq.UpdatableRecord.update.

Doc from org.jooq.UpdatableRecord.update.

Store parts of this record to the database using an UPDATE statement.

Returns:int

1 if the record was stored to the database. 0 if storing was not necessary.

Annotations

@Override

Implements org.jooq.UpdatableRecord.update.

Doc from org.jooq.UpdatableRecord.update.

Store parts of this record to the database using an UPDATE statement.

Returns:int

1 if the record was stored to the database. 0 if storing was not necessary.

Annotations

@Override