R
- The record typepublic interface TableRecord<R extends TableRecord<R>> extends Record
Modifier and Type | Method and Description |
---|---|
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
|
R |
original()
Get this record containing the original values as fetched from the
database.
|
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.
|
changed, from, getValue, getValue, getValue, getValue, 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, map, setValue, setValue, size
getField, getField, getField, getFields, getIndex
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
attach
internalAPI
@Deprecated int storeUsing(TableField<R,?>... keys) throws DataAccessException, DataChangedException
Depending on the state of the provided keys' value, an
INSERT
or an UPDATE
statement is executed.
INSERT
statement is executedINSERT
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.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.
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
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.
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:
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.
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
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]
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.DataAccessException
- if something went wrong executing the queryDataChangedException
- If optimistic locking is enabled and the
record has already been changed/deleted in the database@Deprecated int deleteUsing(TableField<R,?>... keys) throws DataAccessException, DataChangedException
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:
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.
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
The executed statement is
DELETE FROM [table]
WHERE [key fields = key values]
AND [version/timestamp fields = version/timestamp values]
keys
- The key fields for the DELETE
statement's
WHERE
clause.DataAccessException
- if something went wrong executing the queryDataChangedException
- If optimistic locking is enabled and the
record has already been changed/deleted in the database@Deprecated void refreshUsing(TableField<R,?>... keys) throws DataAccessException
The executed statement is
SELECT * FROM [table]
WHERE [key fields = key values]
keys
- The key fields for the SELECT
statement's
WHERE
clause.DataAccessException
- This exception is thrown if
R original()
Record values can be freely modified after having fetched a record from the database. Every record also references the originally fetched values. This method returns a new record containing those original values.
Copyright © 2013. All Rights Reserved.