Answers.Body: <p>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).</p>
  
  <p>You will notice the triggers are then rebuild before the function exits: <a href="https://github.com/civicrm/civicrm-core/blob/1e7702fee94c891c1c1b3ec4d43688991f96b6af/CRM/Contact/BAO/ContactType.php#L921" rel="nofollow">https://github.com/civicrm/civicrm-core/blob/1e7702fee94c891c1c1b3ec4d43688991f96b6af/CRM/Contact/BAO/ContactType.php#L921</a></p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-06-23T12:33:13.820Z
Answers.Text: But presumably other tasks could be running simultaneously, which might rely on or be affected by those triggers?
Answers.UserDisplayName: John
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-06-24T15:00:49.147Z
Answers.Text: 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.
Answers.UserDisplayName: cividesk
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-06-23T04:45:19.417Z
Answers.LastActivityDate: 2016-06-23T04:45:19.417Z
Answers.UserDisplayName: cividesk
Body: <p>I've spotted at least one process in CiviCRM that drop triggers on certain tables in order to run a process. For example:
  <a href="https://github.com/civicrm/civicrm-core/blob/1e7702fee94c891c1c1b3ec4d43688991f96b6af/CRM/Contact/BAO/ContactType.php#L904" rel="nofollow">https://github.com/civicrm/civicrm-core/blob/1e7702fee94c891c1c1b3ec4d43688991f96b6af/CRM/Contact/BAO/ContactType.php#L904</a></p>
  
  <p>Is this a bug?</p>
  
  <p>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)?</p>
  
Tags: <database><developer>
Title: Is it OK to drop database triggers in order to run a process?
ThreadText: # Is it OK to drop database triggers in order to run a process?
  
  (Asked by: username_0 on 2016-05-13)
  
  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)?
  
  **Tags:** database, developer
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2016-06-23. Score: 1 | Accepted answer
  
  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>
  
  > **Comments:**
  > **username_0**: But presumably other tasks could be running simultaneously, which might rely on or be affected by those triggers?  
  > **username_1**: 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.  
  
  ---
  
  