18.4.8.4.4 Lost Update Protection
Learn about BOSS REST Data Source lost update protection.
When an end user modifies one or more rows of data from a BOSS REST Data Source, APEX enforces lost update protection. If the user inserts four new rows in an
interactive grid region, modifies three rows, and deletes two rows, when they click
Save, the APEX engine performs the lost update protection checks for the five updated and
deleted rows by retrieving each one using its resource key from the BOSS REST
endpoint. If the BOSS REST Data Source has an ETag, you can use the
APEX$ETAG column as the row version column for more efficient
lost update detection checks by configuring the Lost Update
Type on a form or grid to be Row Version
Column and configuring APEX$ETAG as the row version
column name.
Note:
When working with a BOSS object that has an attribute of type
historyType='versionNumber', then it is mandatory to always include the
ETag column (by default named APEX$ETAG) in
the list of columns used by a form region, grid region, or in programmatic use with
APEX_EXEC package. Furthermore, it is important when defining
the column to work with programmatically to mark the ETag column
using the p_is_checksum => true parameter to
apex_exec.add_column(). If the business object does not have an
attribute of type historyType='versionNumber', the the object will
not have an ETag. In that case, you can delete the
APEX$ETAG column from the Data Profile as its value will always
be null and will not be used during updates or deletes.
Parent topic: BOSS REST Data Source Runtime Features