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.
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.
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.
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.
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.
@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.
# Conflicts: # backend/core/models/migrationscripts/register.go
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. |
|
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_commitsandpull_request_commentstables.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.