-
Notifications
You must be signed in to change notification settings - Fork 535
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
adding pull_request_id index to pull_request_commits/comments tables #7559
Conversation
type addPullRequestIdIndexToPullRequestCommits struct{} | ||
|
||
type pullRequestCommits20240602 struct { | ||
PullRequestId string `gorm:"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.
https://github.com/apache/incubator-devlake/blob/main/backend/core/models/domainlayer/code/pull_request_commit.go#L28, PullRequestId
and CommitSha
are the primary keys, and it works as expected in db tables.
So I think there is no need to add a new index
in this field.
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.
true in case you are filtering by CommitSha
or CommitSha
+ PullRequestId
.
If you are filtering only by PullRequestId
the composite index won't be used - docs
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.
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.
Ahh.. The order of the primary key columns seems off to me, the PullRequestId
should be placed before the CommitSha
column.
However, adding a secondary index is acceptable IMO if adjusting the order is too hard to do so.
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 could work I think:
ALTER TABLE pull_request_commits DROP PRIMARY KEY;
ALTER TABLE pull_request_commits ADD PRIMARY KEY (pull_request_id, commit_sha);
However, this change might impact the rest of the application, especially if there are custom queries that end users have that expect commit_sha
to be first in the index sequence.
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.
@sstojak1 True, we should consider which one is more likely to happen. It is easier to predict someone might need to group records by pull_request_id
while it is harder to think of how commit_sha
being prioritized could be beneficial for any case, maybe "Counting how many PRs contain the same commit?" which doesn't make too much sense.
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.
# Conflicts: # backend/core/models/migrationscripts/register.go
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.
Why are two tables handled differently?
Besides, can we support postgresql as well? Apache DevLake supports pg as a storage option.
Those two tables don't have the same primary key definition. That's the reason why migration scripts are different. Is the PostgreSQL supported? There are also a few scripts where this kind of schema check is added... |
Hi @klesh any updates here? Did you manage to check my last comment? |
@sstojak1 Hi, sorry for the late reply. |
@sstojak1 And yes, we have some scripts designated MySQL, sometimes because they are MySQL specific nuances, which were unnecessary for PG from what I know. |
@klesh makes sense, thanks for the info. I have added support for PostgreSQL. Please take a look. |
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.
LGTM
Hi, @sstojak1 we are so close, there is one conflict left before I can merge the PR. Would you like to resolve it? Thanks. |
# Conflicts: # backend/core/models/migrationscripts/register.go
@klesh done! |
@klesh can we merge it? :) |
…7559) * adding pull_request_id index to pull_request_commits/comments tables * change the pull_request_commits primary key columns order * adding Apache license header * only run for mysql * adding support for postgres --------- Co-authored-by: Josip Stojak <Josip.Stojak@infobip.com>
…7559) * adding pull_request_id index to pull_request_commits/comments tables * change the pull_request_commits primary key columns order * adding Apache license header * only run for mysql * adding support for postgres --------- Co-authored-by: Josip Stojak <Josip.Stojak@infobip.com>
…7559) (#7744) * adding pull_request_id index to pull_request_commits/comments tables * change the pull_request_commits primary key columns order * adding Apache license header * only run for mysql * adding support for postgres --------- Co-authored-by: sstojak1 <18380216+sstojak1@users.noreply.github.com> Co-authored-by: Josip Stojak <Josip.Stojak@infobip.com>
@sstojak1 Already released in v1.0.1-beta3 |
pr-type/bug-fix
,pr-type/feature-development
, etc.Summary
What does this PR do?
Adding pull_request_id index to
pull_request_commits
andpull_request_comments
tables.Does this close any open issues?
Closes 7557
Screenshots
Include any relevant screenshots here.
Other Information
Any other information that is important to this PR.