-
Notifications
You must be signed in to change notification settings - Fork 15
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
Reset TestPlanVersion nextval
during import if IDs aren't used
#1153
Conversation
nextval
during import if IDs aren't used
id | ||
status | ||
} | ||
v2TestPlanVersion: testPlanVersion(id: 80) { |
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.
For reviewers: Formatting has messed with this diff. This id was changed to 80 from 133
directory | ||
} | ||
} | ||
recommendedTestPlanVersion: testPlanVersion(id: 67) { |
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.
For reviewers: Formatting has messed with this diff. This id was changed to 67 from 69
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 fix makes sense and I tested rebuilding the DB and migrating a production dump without encountering any issues.
{ transaction } | ||
); | ||
const currentTestPlanVersionId = | ||
currentTestPlanVersionIdResult[0].currval - 1; |
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.
Took me a second to understand why currval -1
works here even with the comment helping explain but I eventually understood and the approach makes sense.
Includes the following changes: **Features and Fixes** * #1125 * #1135 * #1144 * #1146 * #1150 * #1152 * #1153 * #1160 **Infrastructure changes** * #969 * #1151 * #1148 --------- Co-authored-by: alflennik <[email protected]> Co-authored-by: Mx Corey Frang <[email protected]> Co-authored-by: cypress evelyn masso <[email protected]> Co-authored-by: Stalgia Grigg <[email protected]>
I was inspecting the production's data from July 10 2024 and took note of significantly high id numbers in the
TestPlanVersion
table. The latest row's id is163615
but there is just 103 rows in the table, which uses auto-increment IDs. Runningselect currval(pg_get_serial_sequence('"TestPlanVersion"', 'id'))
also gives175465
.This happens because the
import-tests
script is dependent on knowing the "next" id to create relevant data that is retrieved using postgres' nextval (which also also updates the next possible ID value). The issue with this is that those ids could go unused if a potential TestPlanVersion being created is "discarded" if non-unique data is found, but the incremented value is left as is.The amount of test plan versions that could be imported is 35 and the cronjob responsible for doing that should run every 15 minutes . So potentially, the incremented value is unnecessarily bumped 140 times per hour (105 at a minimum) if there are no new test plan versions.
So this PR does the following:
nextval
if it hasn't been used due to that non-unique data condition (continued usingnextval
for the evaluation of the reset value becausecurrval
orlastval
may not successfully run ifnextval
hasn't been ran during the db's transaction session)nextval
to current latest ID + 1 in a migration