org.jooq
Interface UpdatableRecord<R extends UpdatableRecord<R>>

Type Parameters:

R - The record type

All Superinterfaces:

Adapter, Attachable, FieldProvider, Record, Serializable, Store<Object>, TableRecord<R>, Updatable<R>

All Known Implementing Classes:

UpdatableRecordImpl

public interface UpdatableRecord<R extends UpdatableRecord<R>>
extends Updatable<R>, TableRecord<R>

A common interface for records that can be stored back to the database again.

Any Record can be Updatable, if

1. it represents a record from a table or view - a TableRecord
2. its underlying table or view has a "main unique key", i.e. a primary key or at least one unique key

The "main unique key" is used by jOOQ to perform the various operations that can be performed on an UpdatableRecord:

• delete() : Deleting the record
• refresh() : Refreshing the records attributes (or loading it for the first time)
• store() : Storing the record to the database. This executes either an INSERT or an UPDATE statement

UpdatableRecords are Attachable, which means that they hold an underlying Configuration that they can be detached from. They can also be instanciated without any underlying Configuration, in case of which they have to be attached first, in order to be refreshed, stored, or deleted.

Author:

Lukas Eder

Method Summary

R	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.
int	delete() Deletes this record from the database, based on the value of the primary key or main unique key.
UpdatableTable<R>	getTable() The table from which this record was read
void	refresh() Refresh this record from the database, based on the value of the primary key or main unique key.
int	store() Store this record back to the database.

Methods inherited from interface org.jooq.TableRecord

deleteUsing, refreshUsing, storeUsing

Methods inherited from interface org.jooq.Record

from, getValue, getValue, getValue, getValue, getValue, getValue, getValue, getValue, getValue, getValue, getValue, getValue, getValue, getValue, getValueAsArray, getValueAsArray, getValueAsBigDecimal, getValueAsBigDecimal, getValueAsBigDecimal, getValueAsBigDecimal, getValueAsBigInteger, getValueAsBigInteger, getValueAsBigInteger, getValueAsBigInteger, getValueAsBoolean, getValueAsBoolean, getValueAsBoolean, getValueAsBoolean, getValueAsByte, getValueAsByte, getValueAsByte, getValueAsByte, getValueAsDate, getValueAsDate, getValueAsDate, getValueAsDate, getValueAsDouble, getValueAsDouble, getValueAsDouble, getValueAsDouble, getValueAsFloat, getValueAsFloat, getValueAsFloat, getValueAsFloat, getValueAsInteger, getValueAsInteger, getValueAsInteger, getValueAsInteger, getValueAsLong, getValueAsLong, getValueAsLong, getValueAsLong, getValueAsShort, getValueAsShort, getValueAsShort, getValueAsShort, getValueAsString, getValueAsString, getValueAsString, getValueAsString, getValueAsTime, getValueAsTime, getValueAsTime, getValueAsTime, getValueAsTimestamp, getValueAsTimestamp, getValueAsTimestamp, getValueAsTimestamp, into, into, into, intoArray, intoMap, setValue, setValue

Methods inherited from interface org.jooq.FieldProvider

getField, getField, getField, getFields, getIndex

Methods inherited from interface org.jooq.Store

getValue, getValue, getValue, getValue, getValueAsBigDecimal, getValueAsBigDecimal, getValueAsBigInteger, getValueAsBigInteger, getValueAsBoolean, getValueAsBoolean, getValueAsByte, getValueAsByte, getValueAsDate, getValueAsDate, getValueAsDouble, getValueAsDouble, getValueAsFloat, getValueAsFloat, getValueAsInteger, getValueAsInteger, getValueAsLong, getValueAsLong, getValueAsShort, getValueAsShort, getValueAsString, getValueAsString, getValueAsTime, getValueAsTime, getValueAsTimestamp, getValueAsTimestamp, size

Methods inherited from interface org.jooq.Attachable

attach

Methods inherited from interface org.jooq.Adapter

internalAPI

Method Detail

getTable

UpdatableTable<R> getTable()

The table from which this record was read

Specified by:

getTable in interface TableRecord<R extends UpdatableRecord<R>>

store

int store()
          throws DataAccessException,
                 DataChangedException

Store this record back to the database.

Depending on the state of the primary key's or main unique 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, but the primary key value was changed, an INSERT statement is executed. 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

• 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 UpdatableTable.getRecordVersion() or UpdatableTable.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 Factory.insertInto(Table), Factory.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 UpdatableTable.getRecordVersion() or UpdatableTable.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.CUBRID and SQLDialect.SQLSERVER: jOOQ will try to lock the database record using JDBC's ResultSet.TYPE_SCROLL_SENSITIVE and ResultSet.CONCUR_UPDATABLE.
  • 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 LockProvider.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]

This is in fact the same as calling store(getTable().getMainKey().getFieldsArray())

Returns:

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

Throws:

DataAccessException - if something went wrong executing the query

DataChangedException - If optimistic locking is enabled and the record has already been changed/deleted in the database

delete

int delete()
           throws DataAccessException,
                  DataChangedException

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 UpdatableTable.getRecordVersion() or UpdatableTable.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.CUBRID and SQLDialect.SQLSERVER: jOOQ will try to lock the database record using JDBC's ResultSet.TYPE_SCROLL_SENSITIVE and ResultSet.CONCUR_UPDATABLE.
  • 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 LockProvider.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().getMainKey().getFieldsArray())

Returns:

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

Throws:

DataAccessException - if something went wrong executing the query

DataChangedException - If optimistic locking is enabled and the record has already been changed/deleted in the database

refresh

void refresh()
             throws DataAccessException

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

This is in fact the same as calling refresh(getTable().getMainKey().getFieldsArray())

The executed statement is

 SELECT * FROM [table]
 WHERE [main key fields = main key values]

Throws:

DataAccessException - This exception is thrown if

• something went wrong executing the query
• the record does not exist anymore in the database

copy

R 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:

A new record, distinct from this record.