Page MenuHomePhabricator

Ensure fundraising civicrm database triggers are always the same on staging as on production
Closed, DeclinedPublic

Description

Let's do something like, write an alert which dumps triggers and functions from production and staging and diffs the two. Any differences should cause us to scowl.


Snip: example error caused by this problem


I believe something is different again, because a production query failed with:

ERROR 1442 (HY000): Can't update table 'log_civicrm_contact' in stored function/trigger because it is already used
by statement which invoked this stored function/trigger.

See T159455#3069823 and T132527.

Event Timeline

awight triaged this task as Medium priority.Mar 7 2017, 10:18 PM
awight renamed this task from CiviCRM triggers should be the same on staging as on production to Ensure that CiviCRM triggers are always the same on staging as on production.Mar 7 2017, 10:27 PM
awight updated the task description. (Show Details)

Aren't there times when production and staging are intentionaly not in sync, i.e. when we're testing a new civicrm version in staging or whatever. It seems like what we should test is that the triggers in db are in sync with the civicrm instance it serves.

I'm not sure whether this problem should be tackled from a database angle, or from a code/civicrm angle. To me it seems easier to do in civicrm, i.e. to populate the database with schema versioning info, and have civi check that against its own code version.

Jgreen renamed this task from Ensure that CiviCRM triggers are always the same on staging as on production to Ensure fundraising civicrm database triggers are always the same on staging as on production.Jun 21 2018, 6:24 PM

Declining because I don't think this is fixable purely from the Ops side, beyond our current process of coordination around civi code changes.