When updating documents supported by a duality view, some rules must be respected.

1. If a document-updating operation (update, insertion, or deletion) is attempted, and the required privileges are not granted to the current user or the view owner, then an error is raised at the time of the attempt. (See Database Privileges Needed for Duality-View Updating Operations for the relevant privileges.)

2. If an attempted document-updating operation (update, insertion, or deletion) violates any constraints imposed on any tables underlying the duality view, then an error is raised. This includes primary-key, unique, NOT NULL, referential-integrity, and check constraints.

3. If a document-updating operation (update, insertion, or deletion) is attempted, and the view annotations don't allow for that operation, then an error is raised at the time of the attempt.

4. When inserting a document into a duality view, the document must contain all fields that both (1) contribute to the document's ETAG value and (2) correspond to columns of a (non-root) table that are marked update-only or read-only in the view definition. In addition, the corresponding column data must already exist in the table. If these conditions aren't satisfied then an error is raised.

   The values of all fields that correspond to read-only columns also must match the corresponding column values in the table. Otherwise, an error is raised.

   For example, in duality view race_dv the use of the driver table is update-only (annotated WITH NOINSERT UPDATE NODELETE). When inserting a new race document, the document must contain the fields that correspond to driver table columns driver_id and name, and the driver table must already contain data that corresponds to the driver information in that document.

   Similarly, if the driver table were marked read-only in view race_dv (instead of update-only), then the driver information in the input document would need to be the same as the existing data in the table.

5. When deleting an object that's linked to its parent with a one-to-many primary-to-foreign-key relationship, if the object does not have annotation DELETE then it is not cascade-deleted. Instead, the foreign key in each row of the object is set to NULL (assuming that the foreign key does not have a non-NULLable constraint).

   For example, the driver array in view team_dv is NODELETE (implicitly, since it's not annotated DELETE). If you delete a team from view team_dv then the corresponding row is deleted from table team.

   But the corresponding rows in the driver table are not deleted. Instead, each such row is unlinked from the deleted team by setting the value of its foreign key column team_id to SQL NULL.

   Similarly, as a result no driver documents are deleted. But their team information is removed. For the version of the Example 3-2, the value of field teamInfo is set to the empty object ({}). For the version of the Example 3-3, each of the team fields, teamId and team, is set to JSON null.

   What would happen if the use of table driver in the definition of duality view team_dv had the annotation DELETE, allowing deletion? In that case, when deleting a given team all of its drivers would also be deleted. This would mean both deleting those rows from the driver table and deleting all corresponding driver documents.

6. In an update operation that replaces a complete document, all fields defined by the view as contributing to the ETAG value (that is, all fields to which annotation CHECK applies) must be included in the new (replacement) document. Otherwise, an error is raised.

   Note that this rule applies also to the use of Oracle SQL function json_transform when using operator KEEP or REMOVE. If any field contributing to the ETAG value is removed from the document then an error is raised.

7. If a duality view has an underlying table with a foreign key that references a primary or unique key of the same view, then a document-updating operation (update, insertion, or deletion) cannot change the value of that primary or unique key. An attempt to do so raises an error.

8. If a document-updating operation (update, insertion, or deletion) involves updating the same row of an underlying table then it cannot change anything in that row in two different ways. Otherwise, an error is raised.

   For example, this insertion attempt fails because the same row of the driver table (the row with primary-key driver_id value 105) cannot have its driver name be both "George Russell" and "Lewis Hamilton".

   INSERT INTO team_dv VALUES
     ('{"_id"   : 303,
        "name"   : "Mercedes",
        "points" : 0,
        "driver" : [ {"driverId" : 105,
                      "name"     : "George Russell",
                      "points"   : 0},
                     {"driverId" : 105,
                      "name"     : "Lewis Hamilton",
                      "points"   : 0} ]}');

9. If the etag field value embedded in a document sent for an updating operation (update, insertion, or deletion) doesn't match the current database state then an error is raised.

10. If a document-updating operation (update, insertion, or deletion) affects two or more documents supported by the same duality view, then all changes to the data of a given row in an underlying table must be compatible (match). Otherwise, an error is raised. For example, for each driver this operation tries to set the name of the first race ($.race[0].name) to the driver's name ($.name).

    UPDATE driver_dv
      SET data = json_transform(data,
                                SET '$.race[0].name' =
                                json_value(data, '$.name'));

    ERROR at line 1:ORA-42605:
    Cannot update JSON Relational Duality View 'DRIVER_DV':
    cannot modify the same row of the table 'RACE' more than once.