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

Type Parameters:

R - The record type

All Superinterfaces:

Adapter, Attachable, FieldProvider, Record, Serializable, Store<Object>

All Known Subinterfaces:

UpdatableRecord<R>

All Known Implementing Classes:

CustomRecord, TableRecordImpl, UpdatableRecordImpl

public interface TableRecord<R extends TableRecord<R>>
extends Record

A record originating from a single table

Author:

Lukas Eder

Method Summary

int	deleteUsing(TableField<R,?>... keys) Deprecated. - 2.5.0 [#1736] - These methods will be made part of jOOQ's internal API soon. Do not reuse these methods.
Table<R>	getTable() The table from which this record was read
void	refreshUsing(TableField<R,?>... keys) Deprecated. - 2.5.0 [#1736] - These methods will be made part of jOOQ's internal API soon. Do not reuse these methods.
int	storeUsing(TableField<R,?>... keys) Deprecated. - 2.5.0 [#1736] - These methods will be made part of jOOQ's internal API soon. Do not reuse these methods.

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

Table<R> getTable()

The table from which this record was read

storeUsing

@Deprecated
int storeUsing(TableField<R,?>... keys)
               throws DataAccessException,
                      DataChangedException

Deprecated. - 2.5.0 [#1736] - These methods will be made part of jOOQ's internal API soon. Do not reuse these methods.

Store this record back to the database.

Depending on the state of the provided keys' 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 provided keys' 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 provided keys' 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]

Parameters:

keys - The key fields used for deciding whether to execute an INSERT or UPDATE statement. If an UPDATE statement is executed, they are also the key fields for the UPDATE statement's WHERE clause.

Returns:

The number of stored records.

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

deleteUsing

@Deprecated
int deleteUsing(TableField<R,?>... keys)
                throws DataAccessException,
                       DataChangedException

Deprecated. - 2.5.0 [#1736] - These methods will be made part of jOOQ's internal API soon. Do not reuse these methods.

Deletes this record from the database, based on the value of the provided keys.

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]

Parameters:

keys - The key fields for the DELETE statement's WHERE clause.

Returns:

The number of deleted records.

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

refreshUsing

@Deprecated
void refreshUsing(TableField<R,?>... keys)
                  throws DataAccessException

Deprecated. - 2.5.0 [#1736] - These methods will be made part of jOOQ's internal API soon. Do not reuse these methods.

Refresh this record from the database, based on the value of the provided keys.

The executed statement is

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

Parameters:

keys - The key fields for the SELECT statement's WHERE clause.

Throws:

DataAccessException - This exception is thrown if

• something went wrong executing the query
• the record does not exist anymore in the database
• the provided keys return several records.