diff options
author | ThibG <thib@sitedethib.com> | 2019-12-29 05:39:08 +0100 |
---|---|---|
committer | Eugen Rochko <eugen@zeonfederated.com> | 2019-12-29 05:39:08 +0100 |
commit | 1155dc08352c3aa1cb763729122c34a3db6e64ec (patch) | |
tree | a33d5437ff70fbfb4fdc3b093f2af2b5ea9d26e3 /db/migrate/20170924022025_ids_to_bigints2.rb | |
parent | 7ff7ca8c7c8d6612760db93d533a18e83b0a9c70 (diff) |
Fix old migrations failing because of strong_migrations update (#12692)
Fixes #12690 The `strong_migrations` update from ba2eac8824a85aa9541f8070ed7bcd22b9982cc8 introduced a check for `change_column_null` specific to Postgres. This rejects old migrations. This commit just wraps old migrations with `safety_assured` to bypass this check. Alternatives would have been to: - Disable that check entirely (a possibility added in that same `strong_migrations` version) for Mastodon, but it makes sense to write new migrations without such a strong lock. - Rewrite the old migrations to do it in a way that do not require an exclusive lock. I thought fixing those old migrations for performance wasn't worth the pain. Also, if I understand correctly, the next version of `strong_migrations` is going to include a helper to do that. We could update those migrations at that point.
Diffstat (limited to 'db/migrate/20170924022025_ids_to_bigints2.rb')
0 files changed, 0 insertions, 0 deletions