Now that the emaj_assign_table() and emaj_modify_table() functions fa…

…mily handle triggers to ignore at rollback time, remove the emaj_ignore_app_triggers() function. Also force the trigger names to be recorded in ascending order into the rel_ignored_trigger column of emaj_relation.

CHANGES.md

@@ -12,7 +12,8 @@ E-Maj - Change log
     removed.
   * The application triggers to ignore at rollback time can be defined using
     the emaj_assign_table(), emaj_assign_tables(), emaj_modify_table() or
-    emaj_modify_tables()functions.
+    emaj_modify_tables()functions. This replaces the now dropped
+    emaj_ignore_app_trigger() function.
   * Remove the old deprecated versions of E-Maj rollback functions that only
     returned an integer.
   * A fourth parameter in the emaj_import_groups_configuration() functions

docs/en/functionsList.rst

@@ -53,11 +53,6 @@ Tables or sequences level functions
 | :ref:`emaj_get_current_log_table                 | | schema TEXT,                | (log.schema TEXT, log.table TEXT)     |
 | <emaj_get_current_log_table>` (V)                | | table TEXT                  |                                       |
 +--------------------------------------------------+-------------------------------+---------------------------------------+
-| :ref:`emaj_ignore_app_trigger                    | | action TEXT,                | #.triggers INT                        |
-| <emaj_ignore_app_trigger>`                       | | schema TEXT,                |                                       |
-|                                                  | | table TEXT,                 |                                       |
-|                                                  | | trigger TEXT                |                                       |
-+--------------------------------------------------+-------------------------------+---------------------------------------+
 | :ref:`emaj_modify_table                          | | schema TEXT,                | #.tables INT                          |
 | <modify_table>`                                  | | table TEXT,                 |                                       |
 |                                                  | | properties JSONB,           |                                       |

docs/en/groupsCreationFunctions.rst

@@ -160,6 +160,8 @@ If several regular expressions are listed in the "ignored_triggers_profiles" pro
 
 Both "ignored_triggers" and "ignored_triggers_profiles" properties can be used jointly. In this case, the selected triggers set is the union of those listed by the "ignored_triggers" property and those selected by each regular expression of the "ignored_triggers_profiles" property.
 
+More details about the :ref:`management of application triggers<application_triggers>`.
+
 For all these functions, an exclusive lock is set on each table of the concerned table groups, so that the groups stability can be guaranted during these operations.
 
 All these functions return the number of assigned tables or sequences.

docs/en/otherFunctions.rst

@@ -127,33 +127,6 @@ It is possible to build a statement accessing a log table. For instance::
 		|| quote_ident(log_schema) || '.' || quote_ident(log_table)
 		FROM emaj.emaj_get_current_log_table('myschema','mytable');
 
-.. _emaj_ignore_app_trigger:
-
-Not disabling application triggers at E-Maj rollback time
----------------------------------------------------------
-
-Application triggers are automatically disabled during E-Maj rollback operations. Under some circumstances, it may be desirable to keep them enabled (more details :ref:`here <application_triggers>`). The *emaj_ignore_app_trigger()* function achieves this. It allows to add or remove triggers into/from a list of triggers that do not need to be disabled during rollback operations. ::
-
-	SELECT emaj.emaj_ignore_app_trigger(<action>, <schema.name>, <table.name>, <trigger.name>);
-
-The *<action>* parameter accepts 2 values: ‘ADD’ to add a trigger to the list or ‘REMOVE’ to delete a trigger from the list.
-
-The trigger is identified by the 3 components: schema name, table name and trigger name.
-
-The trigger name may contain ‘%’ and ‘_’ wildcard characters. These characters have the same meaning as in the *LIKE* clause of the SQL language. Thus several triggers of a single table can be processed by a unique function call.
-
-The function returns the number of triggers effectively added or removed.
-
-The function does not process E-Maj triggers (log or *TRUNCATE* triggers).
-
-The triggers referenced as “not to be automatically disabled during E-Maj rollbacks” are registered into the *emaj.emaj_ignored_app_trigger* table. This table contains 3 columns:
-
-* trg_schema : schema of the table holding the trigger
-* trg_table : table holding the trigger
-* trg_name : trigger name
-
-In order to know the list of registered triggers, just display the table’s content.
-
 .. _emaj_rollback_activity:
 
 Monitoring rollback operations

docs/en/responsibility.rst

@@ -18,12 +18,14 @@ Management of application triggers
 
 Triggers may have been created on application tables. It is not rare that these triggers perform one or more updates on other tables. In such a case, it is the E-Maj administrator's responsibility to understand the impact of E-Maj rollback operations on tables concerned by triggers, and if needed, to take the appropriate measures.
 
-If the trigger simply adjusts the content of the row to insert or update, the logged data will contain the final columns value. So in case of rollback, the log table contains the right data to process. And as the trigger is by default automatically disabled at rollback time, the trigger cannot disturb the rollback processing.
+By default, E-Maj rollback functions automatically disable application triggers at the operation’s start and reset them in their previous state at operation’s end. But the E-Maj administrator can change this behaviour using the *"ignored_triggers"* and *"ignored_triggers_profiles"* properties of the :ref:`emaj_assign_table(), emaj_assign_tables()<assign_table_sequence>`, :ref:`emaj_modify_table() and emaj_modify_tables()<modify_table>` functions.
+
+If the trigger simply adjusts the content of the row to insert or update, the logged data contain the final columns values. In case of rollback, the log table contains the right columns content to apply. So the trigger must be disabled at rollback time (the default behaviour), so that it does not disturb the processing.
 
 If the trigger updates another table, two cases must be considered:
 
-* if the updated table belongs to the same tables group, the automatic trigger disabling and the rollback of both tables will let them in the expected state,
-* if the updated table does not belong to the same tables group, it is essential to analyse the consequences of a rollback operation, in order to avoid a de-synchronisation between both tables. If needed, the :ref:`emaj_ignore_app_trigger()<emaj_ignore_app_trigger>` function can be used to not disable the trigger at rollback time. But merely deactivating the trigger may not be sufficient and some other actions may be required.
+* if the updated table belongs to the same tables group, the automatic trigger disabling and the rollback of both tables let them in the expected state,
+* if the updated table does not belong to the same tables group, it is essential to analyse the consequences of a rollback operation, in order to avoid a de-synchronisation between both tables. If needed, the triggers can be left enabled. But some other actions may also be required.
 
 For more complex triggers, it is essential to perfectly understand their impacts on E-Maj rollbacks and take any appropriate mesure at rollback time.
 

docs/fr/functionsList.rst

@@ -53,11 +53,6 @@ Fonctions de niveau tables et séquences
 | :ref:`emaj_get_current_log_table                 | | schéma TEXT,                | (schéma.log TEXT, table.log TEXT)     |
 | <emaj_get_current_log_table>` (V)                | | table TEXT                  |                                       |
 +--------------------------------------------------+-------------------------------+---------------------------------------+
-| :ref:`emaj_ignore_app_trigger                    | | action TEXT,                | nb.triggers INT                       |
-| <emaj_ignore_app_trigger>`                       | | schéma TEXT,                |                                       |
-|                                                  | | table TEXT,                 |                                       |
-|                                                  | | trigger TEXT                |                                       |
-+--------------------------------------------------+-------------------------------+---------------------------------------+
 | :ref:`emaj_modify_table                          | | schéma TEXT,                | nb.tables INT                         |
 | <modify_table>`                                  | | table TEXT,                 |                                       |
 |                                                  | | propriétés JSONB,           |                                       |

docs/fr/groupsCreationFunctions.rst

@@ -160,6 +160,8 @@ Si plusieurs expressions rationnelles sont listées dans la propriété "ignored
 
 Les deux propriétés "ignored_triggers" et "ignored_triggers_profiles" peuvent être utilisées conjointement. Dans ce cas, les triggers sélectionnés correspondront à l'union de l'ensemble des triggers listés par la première et des ensembles de triggers sélectionnés par les expressions rationnelles de la seconde.
 
+Davantage d'information sur la :ref:`gestion des triggers applicatifs<application_triggers>`.
+
 Pour toutes les fonctions, un verrou exclusif est posé sur chaque table du ou des groupes de tables concernés, afin de garantir la stabilité des groupes durant ces opérations.
 
 Toutes ces fonctions retournent le nombre de tables ou séquences ajoutées au groupe de tables.

docs/fr/otherFunctions.rst

@@ -126,34 +126,6 @@ Il est ainsi possible de construire une requête accédant à une table de log.
 		|| quote_ident(log_schema) || '.' || quote_ident(log_table)
 		FROM emaj.emaj_get_current_log_table('monschema','matable');
 
-.. _emaj_ignore_app_trigger:
-
-Non désactivation de triggers applicatifs lors des Rollbacks E-Maj
-------------------------------------------------------------------
-
-Les triggers applicatifs sont automatiquement désactivés pendant les opérations de rollback E-Maj. Dans certains cas, il peut être souhaitable de les conserver activés (plus de détails :ref:`ici <application_triggers>`). Pour ce faire, on peut utiliser la fonction *emaj_ignore_app_trigger()*. Elle permet de gérer l’ajout ou la suppression de triggers dans une liste de triggers ne devant pas être désactivés lors des opérations de rollback. ::
-
-	SELECT emaj.emaj_ignore_app_trigger(<action>, <nom.schéma>, <nom.table>, <trigger>);
-
-Le paramètre <action> peut prendre les valeurs *‘ADD’* pour ajouter un trigger à la liste ou *‘REMOVE’* pour supprimer un trigger de la liste.
-
-L’identité du trigger est définie par les 3 composantes nom de schéma, nom de table et nom du trigger.
-
-Le nom du trigger peut contenir des caractères génériques ‘%’ et ‘_’, dont la signification est identique à ceux présents dans les clauses *LIKE* du langage SQL. On peut ainsi traiter plusieurs triggers d’une même table en un seul appel de la fonction.
-
-La fonction retourne le nombre de triggers effectivement ajoutés ou supprimés.
-
-La fonction ne traite pas les triggers E-Maj (trigger de log ou de traitement des *TRUNCATEs*).
-
-Les triggers ainsi référencés comme "ne devant pas être automatiquement désactivés lors des rollbacks E-Maj" sont enregistrés dans la table *emaj.emaj_ignored_app_trigger*. Cette table comprend 3 colonnes :
-
-* trg_schema : schéma de la table portant le trigger
-* trg_table : table portant le trigger
-* trg_name : nom du trigger
-
-Pour connaître la liste des triggers enregistrés, il suffit de lister le contenu de la table.
-
-
 .. _emaj_rollback_activity:
 
 Suivi des opérations de rollback en cours

docs/fr/responsibility.rst

@@ -21,12 +21,14 @@ Gestion des triggers applicatifs
 
 Des triggers peuvent avoir été créés sur des tables applicatives. Il n'est pas rare que ces triggers génèrent une ou des mises à jour sur d'autres tables. Il est alors de la responsabilité de l'administrateur E-Maj de comprendre l'impact des opérations de rollback E-Maj sur les tables concernées par des triggers et de prendre le cas échéant les mesures appropriées.
 
-Si le trigger ajuste simplement le contenu de la ligne à insérer ou modifier, c'est la valeur finale des colonnes qui sera enregistrée dans la table de log. Ainsi en cas de rollback E-Maj, la table de log contiendra les bonnes valeurs de colonne. Et comme le trigger sera par défaut désactivé automatiquement, il ne pourra pas perturber lui même le traitement de rollback.
+Par défaut, les fonctions de rollback E-Maj désactivent automatiquement les triggers applicatifs en début d’opération et les remettent dans leur état précédent en fin d’opération. Mais l’administrateur E-Maj peut modifier ce comportement à l’aide des propriétés *"ignored_triggers"* et *"ignored_triggers_profiles"* des fonctions :ref:`emaj_assign_table(), emaj_assign_tables()<assign_table_sequence>`, :ref:`emaj_modify_table() et emaj_modify_tables()<modify_table>`.
+
+Si le trigger ajuste simplement le contenu de la ligne à insérer ou modifier, c'est la valeur finale des colonnes qui est enregistrée dans la table de log. Ainsi en cas de rollback E-Maj, la table de log contient déjà les bonnes valeurs de colonne à réappliquer. Pour ne pas perturber le traitement du rollback, le trigger doit donc être désactivé (comportement par défaut).
 
 Si le trigger met à jour une autre table, deux cas sont à considérer :
 
-* si la table modifiée par le trigger fait partie du même groupe de tables, la désactivation automatique du trigger et le traitement des deux tables par le rollback vont repositionner ces deux tables dans l’état attendu,
-* si la table modifiée par le trigger ne fait pas partie du même groupe de tables, il est essentiel d'analyser les conséquences du rollback de la table possédant le trigger sur la table modifiée par ce trigger, afin d'éviter que le rollback ne provoque un déphasage entre les 2 tables. Le cas échéant, il peut être nécessaire de faire en sorte de ne pas désactiver le trigger. On utilisera alors la fonction :ref:`emaj_ignore_app_trigger()<emaj_ignore_app_trigger>`. Mais la désactivation du trigger pendant l'opération de rollback peut ne pas être suffisante et d’autres actions peuvent donc être requises.
+* si la table modifiée par le trigger fait partie du même groupe de tables, la désactivation automatique du trigger et le traitement des deux tables par le rollback repositionnent ces deux tables dans l’état attendu,
+* si la table modifiée par le trigger ne fait pas partie du même groupe de tables, il est essentiel d'analyser les conséquences du rollback de la table possédant le trigger sur la table modifiée par ce trigger, afin d'éviter que le rollback ne provoque un déphasage entre les 2 tables. Le cas échéant, il peut être nécessaire de ne pas désactiver le trigger. Mais d’autres actions complémentaires  peuvent aussi être requises.
 
 Pour des triggers plus complexes, il est indispensable de bien comprendre les impacts d’un rollback et de prendre éventuellement les mesures complémentaires appropriées lors des rollbacks E-Maj.