Update MP MPs Modification.md

Author: pchemguy

MP MPs Modification.md

@@ -64,15 +64,19 @@ SELECT * FROM base_ops;
 
 **CREATE/INSERT** operation specifies *path_new* for each new category. The handling script must create any nonexistent ancestors (intermediate categories) automatically.
 
-**DELETE** operation specifies *path_old* for each deleted category subtree. In addition to deleting the specified categories and all their descendants, the script must also delete all category assignment records for each deleted category in many-to-many (MtoM) tables. Script's business logic depends on the specific delete operation scenario.
+**DELETE** operation specifies *path_old* for each deleted category subtree. The database enigne also deletes all category assignment records in many-to-many (MtoM) tables for each deleted category via the foreign key cascades.
 
-A simple approach involves deletion of all associated category rows from the *categories*  table. Because each many-to-many table should include a foreign key to the *categories* table with cascaded deletions, all category assignment operations will be deleted automatically by the database.
+**COPY/MOVE/UPDATE** operations specify *path_old* and *path_new* for each affected category (similarly to FS copy/move operations on  directories). Special consideration is necessary for handling collisions. 
 
-An advanced approach implements the delete operation as *move-to-trash*. In this case, the script uses the MOVE operation, relocating the target subtrees into the system *~Trash* category and using the database UPDATE statement instead of DELETE. The script also appends '~' \|\| *ascii_id* to the names of deleted subtree root nodes to avoid potential name collisions. Here, the deletion of the associated category assignment records from MtoM tables necessitates explicit processing because the UPDATE statement does not trigger deletion cascades.
+I follow the "merge on collide" convention. When the name of a moved/copied/renamed category collides with an existing one, preferably keep the latter. As long as the only category identification used outside the database is its name-based path, any external application would see any difference no matter which conflicting copy remains. So long as the relationship tables use the category's name-based path as the foreign key reference, all records in the MtoM tables can be updated following a simple protocol as if no collision has occurred. Explicit updating of the MtoM tables is still necessary because cascades will not work for merged nodes.
 
-Recall that SQLite does not support dynamic SQL, in general, or conversion of a string name into an object identifier, in particular. For this reason, a library-style script for advanced deletion necessitates tailoring it to a specific set of MtoM tables. Strictly speaking, there is an alternative database protocol for implementing the *move-to-trash* operation (DELETE/INSERT), which triggers the deletion cascades and, thus, permits the creation of a universal script. However, additional planned extensions/features in the future may not be fully compatible with cascaded operations. For this reason, the developed scripts handle relationship tables explicitly, and their simplified versions (not given) let cascades do their part.
+The remaining question is whether the COPY script should copy the associated MtoM records. On the one hand, FS routines usually copy contained files by default. On the other hand, the FS analogy has its limitations, as discussed [previously](../mat-paths/design-rules). Categories only act as containers/directories for other categories, in which case the associated FS logic is relevant to the behavior of the category system. The relationship between categories and categorized items is naturally different from the relationship between directories and files. For this reason, both approaches (copying the associated relationship records following the FS logic and not doing so) may have supporting arguments. The current implementation of the COPY operation does not copy the associated MtoM records.
 
-**COPY/MOVE/UPDATE** operations specify *path_old* and *path_new* for each affected category (similarly to FS copy/move operations on  directories). Special consideration is necessary for handling collisions. I follow the "merge on collide" convention. When the name of a moved/copied/renamed category collides with an existing one, preferably keep existing copy. As long as the only category identification used outside the database is its name-based path, any external application would not be able to see any difference either way. So long as the relationship table uses the category's name-based path as the foreign key reference, all records in the MtoM table can be updated following a simple protocol as if no collision has occurred. Explicit updating of the MtoM tables is still necessary because cascaded updates would fail for merged nodes.
+### Foreing Keys
+
+A common approach to executing a multi-statement modification operation that might temporarily violate foreign key constraints (FKCs) is via the [foreign_keys pragma][]. The [defer_foreign_keys pragma][] provides a safer option. This pragma enables a temporary violation of FKCs within an active transaction. However, the database prevents committing a transaction violating any FKCs, and resets the *defer_foreign_keys* pragma automatically at each COMMIT/ROLLBACK, leaving foreign keys enabled at transaction conclusion.
 
-The remaining question is whether the COPY script should copy the associated MtoM records. On the one hand, FS routines usually copy contained files by default. On the other hand, the FS analogy has its limitations, as discussed [previously](../mat-paths/design-rules). Categories only act as containers/directories for other categories, in which case the associated FS logic is relevant to the behavior of the category system. The relationship between categories and categorized items is naturally different from the relationship between directories and files. For this reason, both approaches (copying the associated relationship records following the FS logic and not doing so) may have supporting arguments. The current implementation of the COPY operation does not copy the associated MtoM records.
 
+<!-- References -->
+[foreign_keys pragma]: https://sqlite.org/pragma.html#pragma_foreign_keys
+[defer_foreign_keys pragma]: https://sqlite.org/pragma.html#pragma_defer_foreign_keys