|
@@ -0,0 +1,52 @@
|
|
|
+# Generated by Django 2.2.24 on 2022-05-03 22:33
|
|
|
+
|
|
|
+from django.db import migrations
|
|
|
+
|
|
|
+from sentry.new_migrations.migrations import CheckedMigration
|
|
|
+from sentry.utils.query import RangeQuerySetWrapperWithProgressBar
|
|
|
+
|
|
|
+
|
|
|
+def backfill_project_has_release(apps, schema_editor):
|
|
|
+ # We have some projects that don't have the `has_release` flag correctly set. We want to go
|
|
|
+ # through all projects and if they don't have `has_release` set, check whether they're
|
|
|
+ # associated with any release and set the flag.
|
|
|
+ Project = apps.get_model("sentry", "Project")
|
|
|
+ ReleaseProject = apps.get_model("sentry", "ReleaseProject")
|
|
|
+ for project in RangeQuerySetWrapperWithProgressBar(Project.objects.all()):
|
|
|
+ if (
|
|
|
+ not project.flags.has_releases
|
|
|
+ and ReleaseProject.objects.filter(project=project).exists()
|
|
|
+ ):
|
|
|
+ project.flags.has_releases = True
|
|
|
+ project.save(update_fields=["flags"])
|
|
|
+
|
|
|
+
|
|
|
+class Migration(CheckedMigration):
|
|
|
+ # This flag is used to mark that a migration shouldn't be automatically run in production. For
|
|
|
+ # the most part, 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 dangerous:
|
|
|
+ # - Large data migrations. Typically we want these to be run manually by ops 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
|
|
|
+ # have ops run this and not block the deploy. Note that while adding an index is a schema
|
|
|
+ # change, it's completely safe to run the operation after the code has deployed.
|
|
|
+ is_dangerous = True
|
|
|
+
|
|
|
+ # This flag is used to decide whether to run this migration in a transaction or not. Generally
|
|
|
+ # we don't want to run in a transaction here, since for long running operations like data
|
|
|
+ # back-fills this results in us locking an increasing number of rows until we finally commit.
|
|
|
+ atomic = False
|
|
|
+
|
|
|
+ dependencies = [
|
|
|
+ ("sentry", "0289_dashboardwidgetquery_convert_orderby_to_field"),
|
|
|
+ ]
|
|
|
+
|
|
|
+ operations = [
|
|
|
+ migrations.RunPython(
|
|
|
+ backfill_project_has_release,
|
|
|
+ migrations.RunPython.noop,
|
|
|
+ hints={"tables": ["sentry_release", "sentry_project", "sentry_releaseproject"]},
|
|
|
+ ),
|
|
|
+ ]
|