Skip to content
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion migrations_lockfile.txt
Original file line number Diff line number Diff line change
Expand Up @@ -17,7 +17,7 @@ hybridcloud: 0024_add_project_distribution_scope

insights: 0002_backfill_team_starred

monitors: 0012_remove_monitor_is_muted_field
monitors: 0013_fix_monitorincident_checkin_cascade

nodestore: 0001_squashed_0002_nodestore_no_dictfield

Expand Down
Original file line number Diff line number Diff line change
@@ -0,0 +1,50 @@
# Generated by Django 5.2.8 on 2025-11-19 23:35

import django.db.models.deletion
from django.db import migrations

import sentry.db.models.fields.foreignkey
from sentry.new_migrations.migrations import CheckedMigration


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 = [
("monitors", "0012_remove_monitor_is_muted_field"),
]

operations = [
migrations.AlterField(
model_name="monitorincident",
name="starting_checkin",
field=sentry.db.models.fields.foreignkey.FlexibleForeignKey(
null=True,
on_delete=django.db.models.deletion.CASCADE,
related_name="created_incidents",
to="monitors.monitorcheckin",
),
),
Comment on lines +30 to +39
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This isn't generating any SQL in CI, and it might not generate any SQL in production either as django's state before this migration is run indicates that the on_delete action is already present. If you use a SeparateDatabaseAndState operation instead you could rebuild the constraint via SQL to ensure that the constraint is created to match django's state.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I notice that we actually do this across the board, that our FKs have Cascades at the django level but not in the DB generally. I think I will solve this in the more canonical way of deleting the child relations manually using a deletion task instead of letting the DB do it, which seems like we dont usually do.

migrations.AlterField(
model_name="monitorincident",
name="resolving_checkin",
field=sentry.db.models.fields.foreignkey.FlexibleForeignKey(
null=True,
on_delete=django.db.models.deletion.CASCADE,
related_name="resolved_incidents",
to="monitors.monitorcheckin",
),
),
]
Loading