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 or DELETE, 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 and name. Similarly, for the fields/columns for table race: race fields _id and name, hence also raceInfo, 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 and finalPosition.

  • All of the fields/columns for table driver can be inserted, updated, and deleted (WITH INSERT UPDATE DELETE) — driver fields _id, name, and points.

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.