tapd+sqlc: separate SQL migrations from code migrations #1881
Conversation
ViktorT-11
changed the title
Summary of ChangesHello @ViktorT-11, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request implements a significant refactoring of the migration system within tapd to align with a new design philosophy that mandates a clear separation between SQL schema changes and application-level code migrations. By extracting existing code migrations from their original combined SQL/code versions (33 and 37) into new, standalone migration files (48 and 49), the system gains greater modularity and clarity. A key focus of this change is ensuring that this transition is seamless for existing users, with robust testing confirming that the re-execution of these now-separated code migrations will not introduce any unintended side effects or data modifications. Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
|
Will address any failing CI checks on Monday. |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request effectively separates SQL migrations from code migrations for versions 33 and 37 by moving the code migration logic to new, dedicated migration versions 48 and 49. This is a solid architectural improvement that enhances the clarity and maintainability of the migration process.
The new tests, TestMigration48ScriptKeyTypeReplay and TestMigration49BurnReplay, are well-designed and crucial for ensuring backward compatibility. They correctly simulate the upgrade path for existing users and verify that re-running the code migrations is idempotent, which is essential for a safe transition.
However, there is one critical issue: the LatestMigrationVersion constant in tapdb/migrations.go has not been updated to 49. The comment for this constant explicitly states that it must be updated when new migrations are added. Failing to do so can compromise the database downgrade protection mechanism. Please ensure this constant is updated to reflect the new latest migration version.
Pull Request Test Coverage Report for Build 19599245137Details
💛 - Coveralls |
Previously, SQL migrations and code migrations have been designed to be a single migration version, where the SQL migration was run first, followed by a post step migration callback that executed the code migration. Due to a re-definition of the migration design, which separates SQL and code migrations, we need to update tapd to become compatible with the new migration design before updating to the new design. This commit therefore separates the code migrations from migration `33` & `37`, into separate migration files, and adds those two new migrations to the `tapdb/sqlc/migrations` directory. Additionally, since users that have already run the code migrations during migration `33` & `37` will have those migrations re-executed once more after updating to this PR, we test that re-execution of those code migrations will be a no-op for those users, and won't add or change any data in the database.
ViktorT-11
force-pushed
the
2025-11-separate-code-migrations
branch
from
0346e31 to
18e9478
Compare
2 participants
Previously, SQL migrations and code migrations have been designed to be a single migration version, where the SQL migration was run first, followed by a post step migration callback that executed the code migration.
Due to a re-definition of the migration design, which separates SQL and code migrations, we need to update tapd to become compatible with the new migration design before updating to the new design.
This PR therefore separates the code migrations from migration
33&37, into separate migration files, and adds those two new migrations to thetapdb/sqlc/migrationsdirectory.Additionally, since users that have already run the code migrations during migration
33&37will have those migrations re-executed once more after updating to this PR, we test that re-execution of those code migrations will be a no-op for those users, and won't add or change any data in the database.