-
-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore(uptime): Modify unique subscription check constraint to allow us to migrate away from it #84875
Conversation
…s to migrate away from it We want to remove the unique subscription constraint. It's getting increasingly complex to maintain it and it breaks in various ways. As a first step, we'll add a migrated column. Once a subscription sets this to `True` then we won't respect the constraint anymore. We'll use this to work on moving subscriptions away from this model.
Codecov ReportAll modified and coverable lines are covered by tests ✅ ✅ All tests successful. No failed tests found. Additional details and impacted files@@ Coverage Diff @@
## master #84875 +/- ##
===========================================
+ Coverage 46.38% 87.89% +41.50%
===========================================
Files 9552 9569 +17
Lines 541139 541887 +748
Branches 20887 20887
===========================================
+ Hits 250997 476278 +225281
+ Misses 289802 65269 -224533
Partials 340 340 |
# 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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be post deployment migration, in US table has 84k rows, not much, but could still cause a timeout since we need to rebuild the index?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be ok - we have a lock acquisition timeout for adding an index, but not a statement timeout.
This PR has a migration; here is the generated SQL for --
-- Add field migrated to uptimesubscription
--
ALTER TABLE "uptime_uptimesubscription" ADD COLUMN "migrated" boolean DEFAULT false NOT NULL;
--
-- Create constraint uptime_uptimesubscription_unique_subscription_check_4 on model uptimesubscription
--
CREATE UNIQUE INDEX CONCURRENTLY "uptime_uptimesubscription_unique_subscription_check_4" ON "uptime_uptimesubscription" ("url", "interval_seconds", "timeout_ms", "method", "trace_sampling", (MD5("headers")), (COALESCE(MD5("body"), ''))) WHERE NOT "migrated";
--
-- Remove constraint uptime_uptimesubscription_unique_subscription_check_3 from model uptimesubscription
--
DROP INDEX CONCURRENTLY IF EXISTS "uptime_uptimesubscription_unique_subscription_check_3"; |
We want to remove the unique subscription constraint. It's getting increasingly complex to maintain it and it breaks in various ways.
As a first step, we'll add a migrated column. Once a subscription sets this to
True
then we won't respect the constraint anymore. We'll use this to work on moving subscriptions away from this model.