migrations(shared-views): backfill existing views with org visibility #88632
Conversation
|
This PR has a migration; here is the generated SQL for --
-- Raw Python operation
--
-- THIS OPERATION CANNOT BE WRITTEN AS SQL |
abd8e0c to
398bb34
Compare
398bb34 to
ac2486b
Compare
ac2486b to
877cf7a
Compare
|
This PR has a migration; here is the generated SQL for --
-- Raw Python operation
--
-- THIS OPERATION CANNOT BE WRITTEN AS SQL |
| for gsv in RangeQuerySetWrapperWithProgressBar(GroupSearchView.objects.all()): | ||
| gsv.visibility = GroupSearchViewVisibility.ORGANIZATION | ||
| gsv.save() |
There was a problem hiding this comment.
This will result in N queries, N being number of GroupSearchView entries in the db.
Can we do instead:
GroupSearchView.objects.all().update(visibility=GroupSearchViewVisibility.ORGANIZATION)
There was a problem hiding this comment.
during a backfill, doing updates one by one is ideal, as to not make too many updates at once which could overwhelm our database / cause lots of row-level-locks at once. some relevant docs at https://develop.sentry.dev/backend/application-domains/database-migrations/#filters. can also look at some of our other backfill migrations, this is generally the pattern used, e.g. https://github.com/getsentry/sentry/blob/7fefef3f4518d5410e928306d70646fae2c8f667/src/sentry/migrations/0704_backfill_rule_user_team.py#L20
There was a problem hiding this comment.
Another reason to do row level updates instead of big batches is statement timeouts. Queries that update 10k+ rows run the risk of getting terminated by query timeouts.
| for gsv in RangeQuerySetWrapperWithProgressBar(GroupSearchView.objects.all()): | ||
| gsv.visibility = GroupSearchViewVisibility.ORGANIZATION | ||
| gsv.save() |
There was a problem hiding this comment.
Another reason to do row level updates instead of big batches is statement timeouts. Queries that update 10k+ rows run the risk of getting terminated by query timeouts.
…#88632) As part of transitioning to a shared-by-default model for views, we need to make all existing views have Organization level visibility. This PR updates all existing views to have org visibility. This visibility column is not used by any public frontend pages, so this will not have any visible effects for users. All entry-points to creating views have been plugged in [this PR](#88630)
As part of transitioning to a shared-by-default model for views, we need to make all existing views have Organization level visibility. This PR updates all existing views to have org visibility.
This visibility column is not used by any public frontend pages, so this will not have any visible effects for users.
All entry-points to creating views have been plugged in this PR