Has anyone attempted to put guardrails around modifying flyway_schema_history? In theory, it should only be modified through Flyway processes, but in practice, it's just a table! Anyone with write permissions could change the data.
A trigger seems like the most immediately straightforward way to prevent someone unauthorized from messing with it, but then that is detectable on the schema model. My context is SQL Server, so perhaps an extended event or audit? Those wouldn't prevent changes being made, but would mean that we would have logs of any time the table had been touched if we started having issues.
Motivation: We ran into an issue at one point where FSH was missing rows even though a Migrate had run, and we have no idea how that might have happened.
Has anyone attempted to put guardrails around modifying flyway_schema_history? In theory, it should only be modified through Flyway processes, but in practice, it's just a table! Anyone with write permissions could change the data.
A trigger seems like the most immediately straightforward way to prevent someone unauthorized from messing with it, but then that is detectable on the schema model. My context is SQL Server, so perhaps an extended event or audit? Those wouldn't prevent changes being made, but would mean that we would have logs of any time the table had been touched if we started having issues.
Motivation: We ran into an issue at one point where FSH was missing rows even though a Migrate had run, and we have no idea how that might have happened.