R
- The record typepublic interface UpdatableRecord<R extends UpdatableRecord<R>> extends TableRecord<R>
Any Record
can be updatable, if
TableRecord
The "main unique key" is used by jOOQ to perform the various operations that
can be performed on an UpdatableRecord
:
delete()
: Deleting the recordrefresh()
: 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 instantiated without any underlying Configuration
, in
case of which they have to be attached first, in order to be refreshed,
stored, or deleted.
Modifier and Type | Method and Description |
---|---|
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.
|
<O extends TableRecord<O>> |
fetchChild(ForeignKey<O,R> key)
Fetch a child record of this record, given a foreign key.
|
<O extends TableRecord<O>> |
fetchChildren(ForeignKey<O,R> key)
Fetch child records of this record, given a foreign key.
|
int |
insert()
Store this record back to the database using an
INSERT
statement. |
int |
insert(Field<?>... fields)
Store parts of this record to the database using an
INSERT
statement. |
Record |
key()
A Record copy holding values for the
Table.getPrimaryKey() . |
void |
refresh()
Refresh this record from the database.
|
void |
refresh(Field<?>... fields)
Refresh parts of this record from the database.
|
int |
store()
Store this record back to the database.
|
int |
store(Field<?>... fields)
Store parts of this record to the database.
|
int |
update()
Store this record back to the database using an
UPDATE
statement. |
int |
update(Field<?>... fields)
Store parts of this record to the database using an
UPDATE
statement. |
fetchParent, getTable, original
changed, changed, changed, changed, changed, changed, changed, changed, compareTo, equals, field, field, field, fields, fields, fields, fields, fieldsRow, from, from, from, from, fromArray, fromArray, fromArray, fromArray, fromMap, fromMap, fromMap, fromMap, getValue, getValue, getValue, getValue, getValue, getValue, getValue, getValue, getValue, getValue, getValue, getValue, getValue, getValue, getValue, getValue, getValue, getValue, hashCode, into, into, into, into, into, into, into, into, into, into, into, into, into, into, into, into, into, into, into, into, into, into, into, into, into, into, intoArray, intoList, intoMap, intoResultSet, map, original, original, original, reset, reset, reset, reset, setValue, setValue, size, valuesRow
attach, detach
Record key()
Table.getPrimaryKey()
.
The returned record consists exactly of those fields as returned by the
table's primary key: Key.getFields()
.
Generated subtypes may covariantly override this method to add more
record type information. For instance, they may return Record1
,
Record2
, ...
int store() throws DataAccessException, DataChangedException
Depending on the state of the primary key's value, an insert()
or an update()
statement is executed.
INSERT
statement is executedINSERT
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.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.
Use insert()
or update()
to explicitly force either
statement type.
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 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.
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
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.
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 SelectQuery.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]
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 Record.changed(boolean)
or for single values with
Record.changed(Field, boolean)
, prior to storing.
This is the same as calling record.store(record.fields())
1
if the record was stored to the database. 0
if storing was not necessary.DataAccessException
- if something went wrong executing the queryDataChangedException
- If optimistic locking is enabled and the
record has already been changed/deleted in the databaseinsert()
,
update()
int store(Field<?>... fields) throws DataAccessException, DataChangedException
1
if the record was stored to the database. 0
if storing was not necessary.DataAccessException
- if something went wrong executing the queryDataChangedException
- If optimistic locking is enabled and the
record has already been changed/deleted in the databasestore()
,
insert(Field...)
,
update(Field...)
int insert() throws DataAccessException
INSERT
statement.
This is the same as store()
, except that an INSERT
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 Record.changed(boolean)
or for single values with
Record.changed(Field, boolean)
, prior to insertion.
This is the same as calling record.insert(record.fields())
insert
in interface TableRecord<R extends UpdatableRecord<R>>
1
if the record was stored to the database. 0
if storing was not necessary.DataAccessException
- if something went wrong executing the querystore()
int insert(Field<?>... fields) throws DataAccessException
INSERT
statement.insert
in interface TableRecord<R extends UpdatableRecord<R>>
1
if the record was stored to the database. 0
if storing was not necessary.DataAccessException
- if something went wrong executing the queryinsert()
int update() throws DataAccessException, DataChangedException
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 Record.changed(boolean)
or for single values with
Record.changed(Field, boolean)
, prior to updating.
This is the same as calling record.update(record.fields())
1
if the record was stored to the database. 0
if storing was not necessary.DataAccessException
- if something went wrong executing the queryDataChangedException
- If optimistic locking is enabled and the
record has already been changed/deleted in the databasestore()
int update(Field<?>... fields) throws DataAccessException, DataChangedException
UPDATE
statement.1
if the record was stored to the database. 0
if storing was not necessary.DataAccessException
- if something went wrong executing the queryDataChangedException
- If optimistic locking is enabled and the
record has already been changed/deleted in the databaseupdate()
int delete() 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
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.
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 SelectQuery.setForUpdate(boolean)
for more details
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())
1
if the record was deleted from the database.
0
if deletion was not necessary.DataAccessException
- if something went wrong executing the queryDataChangedException
- If optimistic locking is enabled and the
record has already been changed/deleted in the databasevoid refresh() throws DataAccessException
A successful refresh results in the following:
Record.valuesRow()
will have been restored to the respective values
from the databaseTableRecord.original()
will match this recordRecord.changed()
will be false
Refreshing can trigger any of the following actions:
SELECT
statement, if this is an
UpdatableRecord
.
This is the same as calling record.refresh(record.fields())
DataAccessException
- This exception is thrown if something went
wrong executing the refresh SELECT
statementNoDataFoundException
- If the record does not exist anymore in the
databasevoid refresh(Field<?>... fields) throws DataAccessException, NoDataFoundException
A successful refresh results in the following:
Record.valuesRow()
will have been restored to the respective values
from the databaseTableRecord.original()
will match this recordRecord.changed()
will be false
Refreshing can trigger any of the following actions:
SELECT
statement, if this is an
UpdatableRecord
.
This is the same as calling record.refresh(record.fields())
DataAccessException
- This exception is thrown if something went
wrong executing the refresh SELECT
statementNoDataFoundException
- If the record does not exist anymore in the
databaseR copy()
store()
will result in an INSERT
statement.this
record.<O extends TableRecord<O>> O fetchChild(ForeignKey<O,R> key) throws TooManyRowsException, DataAccessException
This returns a child record referencing this record through a given
foreign key. If no child record was found, this returns null
DataAccessException
- if something went wrong executing the queryTooManyRowsException
- if the query returned more than one recordForeignKey.fetchChildren(java.util.Collection)
,
ForeignKey.fetchChildren(Record)
,
ForeignKey.fetchChildren(Record...)
<O extends TableRecord<O>> Result<O> fetchChildren(ForeignKey<O,R> key) throws DataAccessException
This returns childs record referencing this record through a given foreign key.
DataAccessException
- if something went wrong executing the queryForeignKey.fetchChildren(java.util.Collection)
,
ForeignKey.fetchChildren(Record)
,
ForeignKey.fetchChildren(Record...)
Copyright © 2015. All Rights Reserved.