#1179 SQL Triggers not updated when modifying the definition of a data synchro task

[Denis]

It seems that the definition of the SQL triggers associated with a Data Synchro Task are built/updated only:
- when the task is created (AfterInsert)
- when running the setup

This can be a problem in the following scenario:
- The data synchro task is created for a class containing 3 attributes: att_1, att_2 and att_3 but defined such as att_1 is synchronized whereas att_2 and att_3 are not.
- Then later on the definition of the task is modified to mark att_2 and att_3 as synchronized (this modification can be made manually or via the REST/JSON webservices in case of a collector script).

The MySQL trigger will not be rebuilt and therefore change of the synchro data affecting only the values of either att_2 or att_3 will not be synchronised.

Note that rebuilding the triggers when the definition is modified is not sufficient, the application should also mark as "modified" all replicas for which the value inside the replica differs from the value inside the (already) synchronised object for the newly synchronized attributes.

[Romain Quetiez]

There is a lot more information into the (duplicate) ticket [#1115]

[Romain Quetiez]

Triggers are built with the whole list of attributes, even if they are ignored by the synchronization policy. I did the following test:
1. Create a synchronization data source on Brand
2. Add the attribute Brand::ref by the mean of an XML customization (production.delta.xml)
3. Run the setup
4. The attribute has been added into the synchronization data source with flag *** update = no***
5. Running the MySQL command "SHOW CREATE TRIGGER synchro_data_brand_6_bu;" shows that the attribute is taken into account.

As a consequence : enabling/disabling an attribute on the synchro data source does not require that the triggers be updated.

[Romain Quetiez]

Did the same but at step 3, I've used the ITSM Designer. Everything went well.

[Romain Quetiez]

The only thing that could happen is the following scenario:
1. Data synchro created
2. The attribute newComer is added and the setup/toolkit is executed
3. The DB is restored (directly on the command line, NOT through the iTop GUI)
4. An attempt is made to feed the data table (inc. the new column) -> failure
5. The missing column is added manually
6. The data table is populated with external data (with the initial trigger)
7. The synchro is run -> no error message, but the behavior is not the expected one.

The issue can be closed as "not reproduced' (Denis + Erwan + Romain).

Should this issue happen again, we could add some feebacks in case an inconsistency has been detected:
1. Add that information to the details of a data source (in the status tab)
2. Add that information to the logs when starting a synchro
This could rely on DataSource::DBCheckConsistency, but this function should be improved to detect that the trigger is insufficient though it exists.

[Xtophe38]

Hello,

We (Denis + Christophe) saw that, when a synchro policy was updated, the related trigger was not updated. We verified as well that a setup was not correcting the trigger and that the only way to correct it was to deleted it from the database and to run the setup again.

Christophe