You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 29, 2023. It is now read-only.
We use zero_downtime_migrations at Plated and rely on it pretty heavily for alerting us to dangerous migration situations. However, I recently introduced a PR to our codebase to add a foreign key to a large table we have -- via add_foreign_key -- and was alerted by another developer of ours that this is actually extremely dangerous as it completely locks the table in Postgres: https://travisofthenorth.com/blog/2017/2/2/postgres-adding-foreign-keys-with-zero-downtime
I was thinking this would be a great candidate for a warning from this gem. Unfortunately there doesn't appear to be a way of doing this more safely (in Rails or SQL), as there is with indices (i.e. algorithm: :concurrently), but I do think at the very least the gem should warn about adding foreign keys and force you to wrap add_foreign_key in safety_assured so you are forced to be aware of this scenario and have to consciously make the decision to go ahead anyway. Happy to introduce a PR to this effect. Thoughts?
The text was updated successfully, but these errors were encountered:
nikolai-b
added a commit
to nikolai-b/zero_downtime_migrations
that referenced
this issue
Nov 20, 2018
We use zero_downtime_migrations at Plated and rely on it pretty heavily for alerting us to dangerous migration situations. However, I recently introduced a PR to our codebase to add a foreign key to a large table we have -- via
add_foreign_key
-- and was alerted by another developer of ours that this is actually extremely dangerous as it completely locks the table in Postgres:https://travisofthenorth.com/blog/2017/2/2/postgres-adding-foreign-keys-with-zero-downtime
I was thinking this would be a great candidate for a warning from this gem. Unfortunately there doesn't appear to be a way of doing this more safely (in Rails or SQL), as there is with indices (i.e.
algorithm: :concurrently
), but I do think at the very least the gem should warn about adding foreign keys and force you to wrapadd_foreign_key
insafety_assured
so you are forced to be aware of this scenario and have to consciously make the decision to go ahead anyway. Happy to introduce a PR to this effect. Thoughts?The text was updated successfully, but these errors were encountered: