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 T186355#3069823 and T132527.
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | Jgreen | T183138 fundraising database improvements for 2018 | |||
| Declined | None | T159507 Ensure fundraising civicrm database triggers are always the same on staging as on production |
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.
Declining because I don't think this is fixable purely from the Ops side, beyond our current process of coordination around civi code changes.