diff --git a/migrations_lockfile.txt b/migrations_lockfile.txt index 357d2c4d04952d..f9636cb0a278ce 100644 --- a/migrations_lockfile.txt +++ b/migrations_lockfile.txt @@ -29,9 +29,9 @@ releases: 0004_cleanup_failed_safe_deletes replays: 0007_organizationmember_replay_access -seer: 0016_remove_old_fks +seer: 0017_drop_old_fk_columns -sentry: 1098_remove_old_fks +sentry: 1099_drop_old_fk_columns social_auth: 0003_social_auth_json_field diff --git a/src/sentry/migrations/1099_drop_old_fk_columns.py b/src/sentry/migrations/1099_drop_old_fk_columns.py new file mode 100644 index 00000000000000..d1665036a0852b --- /dev/null +++ b/src/sentry/migrations/1099_drop_old_fk_columns.py @@ -0,0 +1,36 @@ +from sentry.new_migrations.migrations import CheckedMigration +from sentry.new_migrations.monkey.fields import SafeRemoveField +from sentry.new_migrations.monkey.state import DeletionAction + + +class Migration(CheckedMigration): + # This flag is used to mark that a migration shouldn't be automatically run in production. + # This should only be used for operations where it's safe to run the migration after your + # code has deployed. So this should not be used for most operations that alter the schema + # of a table. + # Here are some things that make sense to mark as post deployment: + # - Large data migrations. Typically we want these to be run manually so that they can be + # monitored and not block the deploy for a long period of time while they run. + # - Adding indexes to large tables. Since this can take a long time, we'd generally prefer to + # run this outside deployments so that we don't block them. Note that while adding an index + # is a schema change, it's completely safe to run the operation after the code has deployed. + # Once deployed, run these manually via: https://develop.sentry.dev/database-migrations/#migration-deployment + + is_post_deployment = False + + dependencies = [ + ("sentry", "1098_remove_old_fks"), + ] + + operations = [ + SafeRemoveField( + model_name="repositoryprojectpathconfig", + name="project", + deletion_action=DeletionAction.DELETE, + ), + SafeRemoveField( + model_name="repositoryprojectpathconfig", + name="repository", + deletion_action=DeletionAction.DELETE, + ), + ] diff --git a/src/sentry/seer/migrations/0017_drop_old_fk_columns.py b/src/sentry/seer/migrations/0017_drop_old_fk_columns.py new file mode 100644 index 00000000000000..79a5cfd7b1006b --- /dev/null +++ b/src/sentry/seer/migrations/0017_drop_old_fk_columns.py @@ -0,0 +1,36 @@ +from sentry.new_migrations.migrations import CheckedMigration +from sentry.new_migrations.monkey.fields import SafeRemoveField +from sentry.new_migrations.monkey.state import DeletionAction + + +class Migration(CheckedMigration): + # This flag is used to mark that a migration shouldn't be automatically run in production. + # This should only be used for operations where it's safe to run the migration after your + # code has deployed. So this should not be used for most operations that alter the schema + # of a table. + # Here are some things that make sense to mark as post deployment: + # - Large data migrations. Typically we want these to be run manually so that they can be + # monitored and not block the deploy for a long period of time while they run. + # - Adding indexes to large tables. Since this can take a long time, we'd generally prefer to + # run this outside deployments so that we don't block them. Note that while adding an index + # is a schema change, it's completely safe to run the operation after the code has deployed. + # Once deployed, run these manually via: https://develop.sentry.dev/database-migrations/#migration-deployment + + is_post_deployment = False + + dependencies = [ + ("seer", "0016_remove_old_fks"), + ] + + operations = [ + SafeRemoveField( + model_name="seerprojectrepository", + name="project", + deletion_action=DeletionAction.DELETE, + ), + SafeRemoveField( + model_name="seerprojectrepository", + name="repository", + deletion_action=DeletionAction.DELETE, + ), + ]