3

I've spotted at least one process in CiviCRM that drop triggers on certain tables in order to run a process. For example: https://github.com/civicrm/civicrm-core/blob/1e7702fee94c891c1c1b3ec4d43688991f96b6af/CRM/Contact/BAO/ContactType.php#L904

Is this a bug?

If an operation happens simultaneously that would affect the table which has had its triggers removed, wouldn't that cause data integrity issues, or gaps in logging (which uses database triggers)?

Improve this question

1 Answer 1

Reset to default
1

This is not a bug, we need the triggers to be dropped for performing the database operations in subsequent code lines without having a cascading effect on other tables (a lot of these triggers are on the DELETE operator).

You will notice the triggers are then rebuild before the function exits: https://github.com/civicrm/civicrm-core/blob/1e7702fee94c891c1c1b3ec4d43688991f96b6af/CRM/Contact/BAO/ContactType.php#L921

Improve this answer
2
  • But presumably other tasks could be running simultaneously, which might rely on or be affected by those triggers?
    – John
    Commented Jun 23, 2016 at 12:33
  • That is correct, but a) the triggers are mostly here to delete related data in other tables. If they are not executed then we just have extra row in related tables, which is not a big deal b) the operation in question is quick, so the time the database is without triggers enabled would be in milliseconds and c) the only other options would be to shut down the application (physically on the database server, or with an in-app 'maintenance mode') which seems exaggerated in this case.
    – cividesk
    Commented Jun 24, 2016 at 15:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.