GitLab

DB schema generated by a migration may look different in
rails 4 and 5 (because rails 5 may use different default values).
For this reason it's important to explicitly set for which rails
version a migration was written for.

See https://stackoverflow.com/questions/35929869/activerecordmigration-deprecation-warning-asks-for-rails-version-but-im-no/35930912#35930912

it will decide the method for disable statement_timeout upon
per transaction or per session, based on how it's called.

When calling with a block, block will be executed and it will use
session based statement_timeout, otherwise will default to existing
behavior.

Closes #43887.

This changes the migration ProjectForeignKeysWithCascadingDeletes so
that it does not add already existing foreign keys and indexes, making
it easier to re-run the migration.

This removes the need for relying on Rails' "dependent" option for data
removal, which is _incredibly_ slow (even when using :delete_all) when
deleting large amounts of data. This also ensures data consistency is
enforced on DB level and not on application level (something Rails is
really bad at).

This commit also includes various migrations to add foreign keys to
tables that eventually point to "projects" to ensure no rows get
orphaned upon removing a project.