4.1 Annotations (NO)UPDATE, (NO)INSERT, (NO)DELETE, To Allow/Disallow Updating Operations
Keyword UPDATE
means that the annotated data can be
updated. Keywords INSERT
and DELETE
mean that the
fields/columns covered by the annotation can be inserted or deleted,
respectively.
Various updating operations (insert, delete, update) can be allowed on the data of a duality view. You specify which operations are allowed when you create the view, using table and column annotations. The operations allowed are based on annotations of its root table and other tables or their columns, as follows:
-
The data of a duality view is insertable or deletable if its root table is annotated with keyword
INSERT
orDELETE
, respectively. -
A duality view is updatable if any table or column used in its definition is annotated with keyword
UPDATE
.
By default, duality views are read-only: no table data used to define
a duality view can be modified through the view. This means that the data of the duality
view itself is, by default, not insertable, deletable, or updatable. The keywords
NOUPDATE
, NOINSERT
, and NODELETE
thus pertain by default for all FROM
clauses defining a duality view.
You can specify table-level updatability for a given
FROM
clause by following the table name with keyword
WITH
followed by one or more of the keywords:
(NO
)UPDATE
,
(NO
)INSERT
, and
(NO
)DELETE
. Table-level updatability
defines that of all columns governed by the same FROM
clause,
except for any that have overriding column-level
(NO
)UPDATE
annotations. (Column-level overrides
table-level.)
You can specify that a column-level part of a duality view
(corresponding to a JSON-document field) is updatable using annotation
WITH
after the field–column (key–value) specification,
followed by keyword UPDATE
or NOUPDATE
. For example,
'name' : r.name WITH UPDATE
specifies that field
name
and column r.name
are updatable, even if
table
r
is declared with NOUPDATE
.
Identifying columns, however, are always read-only, regardless
of any annotations. Table-level annotations have no effect on identifying columns, and
applying an UPDATE
annotation to an identifying column raises an
error.
Note:
An attempt to update a column annotated with both NOCHECK
and
NOUPDATE
does not raise an error; the update request is simply
ignored. This is to prevent interfering with possible concurrency.
Updatability annotations are used in Example 3-2 and Example 3-3 as follows:
-
None of the fields/columns for table
team
can be inserted, deleted or updated (WITH NOINSERT NOUPDATE NODELETE
) — team fields_id
andname
. Similarly, for the fields/columns for tablerace
: race fields_id
andname
, hence alsoraceInfo
, can't be inserted, deleted or updated. -
All of the fields/columns for mapping table
driver_race_map
can be inserted and updated, but not deleted (WITH INSERT UPDATE NODELETE
) — fields_id
andfinalPosition
. -
All of the fields/columns for table
driver
can be inserted, updated, and deleted (WITH INSERT UPDATE DELETE
) — driver fields_id
,name
, andpoints
.
In duality views driver_dv
and team_dv
there are only table-level updatability annotations (no column-level annotations). In
view race_dv
, however, field laps
(column
laps
of table race
) has annotation WITH
NOUPDATE
, which overrides the table-level updating allowance for columns of
table race
— you cannot change the number of laps defined for a given
race.
Parent topic: Updatable JSON-Relational Duality Views