Closed benoitblanc closed 1 year ago
ponceta
commented
1 year ago With this, will the audit triggers be activated on the upcoming 1.4.0 dump?
👍 This is a good thing and separating test from ugrade is much better in terms of use and lisibility.
We used to disable audit triggers before any datamodel update to avoid filling up the log tables with data from the datamodel upgrade (keep these only for user actions) but I'm open to suggestions and good practices!
benoitblanc
commented
1 year ago With this, will the audit triggers be activated on the upcoming 1.4.0 dump?
No, audit triggers are only activated in qwat_test to allow the pum check command to not return differences between qwat_test and qwat_comp. Then, qwat_prod is upgraded with deltas and there is no activation of audit triggers in 1.4.0
We used to disable audit triggers before any datamodel update to avoid filling up the log tables with data from the datamodel upgrade (keep these only for user actions) but I'm open to suggestions and good practices!
Yes, I have just understood that audit triggers were deactivated with pre-all.sql before upgrading. But the problem here is between qwat_comp which is initialized with audit triggers through data-model (audit_views.sql) and qwat_test that is restored with 1.3.6 dump (without audit triggers) and upgraded with delta files. In result, qwat_comp has audit triggers and qwat_test hasn't.
I don't know why there is now this problem when I try to upgrade my database to 1.4.0 from 1.3.6 dump, I have never had some similar issue...
ponceta
commented
1 year ago I've opened an issue for the dump.
https://github.com/qwat/qwat-data-model/issues/374
pre and post upgrade scripts enable and disable triggers.
Fix for upgrading production database by manually doing it with pum because audit triggers are not in 1.3.6 dump, but it is present in initialisation script.