-
-
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
migration(shared-views): Add visibility column to groupsearchview table #86440
base: master
Are you sure you want to change the base?
Conversation
❌ 1 Tests Failed:
View the full list of 1 ❄️ flaky tests
To view more test analytics, go to the Test Analytics Dashboard |
@@ -37,6 +52,10 @@ class GroupSearchView(DefaultFieldsModelExisting): | |||
user_id = HybridCloudForeignKey("sentry.User", on_delete="CASCADE") | |||
organization = FlexibleForeignKey("sentry.Organization") | |||
|
|||
visibility = models.CharField( |
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.
i think using a CharField is fine here, but at what scale would it make sense to use an integer mapping for this instead? e.g
sentry/src/sentry/models/group.py
Line 158 in 01dd303
class GroupStatus: |
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.
That's a good question that I'm not really sure how to answer. To me, it seems like the only benefit of switching to an integer mapping is marginally better performance in a couple niche areas. It's hard to draw a line for when those performance improvements actually warrant a refactor. What do you think?
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.
yes, if we did high volume queries and needed to eek out a bit more performance, it would help with that. in addition, it saves a small amount of data, which could be important if this table needed to scale to billions of rows. likely not, but something to consider for bigger tables (e.g. anything to do with GroupedMessage).
given that this view in general will be constrained by user action and never grow that large, it is probably safe to assume that our current char based column will be fine.
This PR has a migration; here is the generated SQL for --
-- Add field visibility to groupsearchview
--
ALTER TABLE "sentry_groupsearchview" ADD COLUMN "visibility" varchar(16) DEFAULT 'owner' NOT NULL; |
Adds a
visibility
enum column to thegroupsearchview
table. As the name implies, this will be used to inform what visibility scope a view has in the future.This is also designed to be extensible to allow for new visibility scopes in the future. We're planning to have "team" and "system" (sentry presets) in the future.