Skip to content
Snippets Groups Projects
Select Git revision
  • 6245075158f5bf79a329e16b9b1622a790524b4b
  • main default protected
  • mathstodon-4.3.6
  • mathstodon-4.3.x
  • mathstodon-4.2.15
  • mathstodon-4.2.10
  • mathstodon-4.2.7
  • mathstodon-4.2.6
  • v4.2.5
  • v4.2.2
  • mathstodon-4.2.5
  • mathstodon-4.2
  • mathstodon-4.1
  • mastodon-4.1.3
  • v4.1.3
  • v4.1.0-diff
  • mathstodon-4.1.0
  • mastodon-v4.1.0
  • v4.0.2
  • mathstodon-4.0.2
  • mathstodon-3.5.3
  • v4.0.0rc3
  • v4.0.0rc2
  • v4.0.0rc1
  • v3.5.3
  • v3.4.8
  • v3.5.2
  • v3.5.1
  • v3.4.7
  • v3.3.3
  • v3.5.0
  • v3.5.0rc3
  • v3.5.0rc2
  • v3.5.0rc1
  • v3.4.6
  • v3.3.2
  • v3.3.1
  • v3.4.5
  • v3.4.4
  • v3.4.3
  • v3.4.2
41 results

db

user avatar
ThibG authored and Eugen Rochko committed
Fixes #12690

The `strong_migrations` update from ba2eac88
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.
1155dc08
History
Name Last commit Last update
..
migrate
post_migrate
schema.rb
seeds.rb