RMB-992: Don't increment optimistic locking _version when updating non-jsonb columns

Some code like
https://folio-org.atlassian.net/browse/MODINVSTOR-1105
https://github.com/folio-org/mod-inventory-storage/pull/926/files
maintains an additional derived column like complete_updated_date.

Only updates of the jsonb column should trigger an _version increment,
not updates of other columns like complete_updated_date.

Other columns are derived values and therefore don’t need optimistic locking.

If developers manually add a column that requires optimistic locking they can
manually adjust the optimistic locking trigger accordingly. Columns not
maintained by RMB are out of scope of RMB’s optimistic locking support.

(cherry picked from commit cb22ee7)

Author: julianladisch

README.md

@@ -1983,7 +1983,7 @@ RMB is aware of the [metadata.schema](https://github.com/folio-org/raml/blob/ram
 
 ## Optimistic Locking
 
-RMB supports optimistic locking. By default it is disabled. Module developers can enable it by adding attribute `withOptimisticLocking` to the table definition in schema.json. The available options are listed below. Unless `off` is specified, a database trigger will be created to auto populate the `_version` field in json on insert. On update a database trigger will check that the `_version` field is the same in the incoming record and in the database, and will then increment the `_version` field before updating the database record. Note, `_version` field has to be defined in json to make this work. PgUtil reports a version conflict error as 409 HTTP response code if 409 is defined in RAML, otherwise, it will fall back to use 400 or 500 HTTP response code. The client should never increment the `_version` property; only the trigger should increment it to ensure that the check and the increment are in the same transaction to avoid any race condition.
+RMB supports optimistic locking. By default it is disabled. Module developers can enable it by adding attribute `withOptimisticLocking` to the table definition in schema.json. The available options are listed below. Unless `off` is specified, a database trigger will be created to auto populate the `_version` field in json on insert. On jsonb column update a database trigger will check that the `_version` field is the same in the incoming record and in the database, and will then increment the `_version` field before updating the database record. Note, `_version` field has to be defined in json to make this work. PgUtil reports a version conflict error as 409 HTTP response code if 409 is defined in RAML, otherwise, it will fall back to use 400 or 500 HTTP response code. The client should never increment the `_version` property; only the trigger should increment it to ensure that the check and the increment are in the same transaction to avoid any race condition.
 
 * `off` Optimistic Locking is disabled. The trigger is removed if it existed before.
 * `failOnConflict` Optimistic Locking is enabled. Version conflict will fail the transaction with a customized SQL error code 23F09.

domain-models-runtime/src/main/resources/templates/db_scripts/optimistic_locking.ftl

@@ -39,7 +39,7 @@
   DROP TRIGGER IF EXISTS set_${table.tableName}_ol_version_trigger
     ON ${myuniversity}_${mymodule}.${table.tableName} CASCADE;
 
-  CREATE TRIGGER set_${table.tableName}_ol_version_trigger BEFORE INSERT OR UPDATE
+  CREATE TRIGGER set_${table.tableName}_ol_version_trigger BEFORE INSERT OR UPDATE OF jsonb
     ON ${myuniversity}_${mymodule}.${table.tableName}
     FOR EACH ROW EXECUTE PROCEDURE ${myuniversity}_${mymodule}.${table.tableName}_set_ol_version();
 

domain-models-runtime/src/test/java/org/folio/rest/persist/ddlgen/SchemaMakerIT.java

@@ -424,7 +424,7 @@ public void canCreateOptimisticLockingTrigger(TestContext context) {
     });
     assertVersion(context, 0, 1, 1, 1);
 
-    // test update
+    // update of jsonb column
     tables.forEach(table -> {
       String updateSql = "UPDATE " + table + " SET jsonb=jsonb_set(jsonb, '{_version}', to_jsonb('2'::text))";
       if (table.equals("tab_ol_fail") || table.equals("tab_ol_fail_suppress")) {
@@ -436,6 +436,12 @@ public void canCreateOptimisticLockingTrigger(TestContext context) {
     });
     assertVersion(context, 2, 2, 1, 1);
 
+    // update of created_by column should not touch _version
+    tables.forEach(table -> {
+      execute(context, "UPDATE " + table + " SET created_by='foo'");
+    });
+    assertVersion(context, 2, 2, 1, 1);
+
     // test insert with provided _version
     tables.forEach(table -> {
       execute(context, "DELETE FROM " + table + "; "

domain-models-runtime/src/test/resources/templates/db_scripts/schemaWithOptimisticLocking.json

@@ -2,22 +2,27 @@
   "tables": [
     {
       "tableName": "tab_ol_off",
-      "withOptimisticLocking": "off"
+      "withOptimisticLocking": "off",
+      "withMetadata": true
     },
     {
       "tableName": "tab_ol_log",
-      "withOptimisticLocking": "logOnConflict"
+      "withOptimisticLocking": "logOnConflict",
+      "withMetadata": true
     },
     {
       "tableName": "tab_ol_fail",
-      "withOptimisticLocking": "failOnConflict"
+      "withOptimisticLocking": "failOnConflict",
+      "withMetadata": true
     },
     {
       "tableName": "tab_ol_fail_suppress",
-      "withOptimisticLocking": "failOnConflictUnlessSuppressed"
+      "withOptimisticLocking": "failOnConflictUnlessSuppressed",
+      "withMetadata": true
     },
     {
-      "tableName": "tab_ol_none"
+      "tableName": "tab_ol_none",
+      "withMetadata": true
     }
   ]
 }