-
Notifications
You must be signed in to change notification settings - Fork 104
[sql-45] package queries & models present at the time of the kvdb to sql migration #1113
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
base: master
Are you sure you want to change the base?
[sql-45] package queries & models present at the time of the kvdb to sql migration #1113
Conversation
We add a helper function to the functions that creates the test SQL stores, in order to ensure that the store is properly closed when the test is cleaned up.
In the upcoming migration of the firewall database to SQL, the helper functions that creates the test databases of different types, need to return a unified interface in order to not have to control the migration tests file by build tags. Therefore, we export the unified interface FirewallDBs, so that it can be returned public test DB creation functions
In the upcoming migration of the firewall database to SQL, the helper functions that creates the test databases of different types, need to return a unified interface in order to not have to control the migration tests file by build tags. Therefore, we update the `NewTestDB` functions to return the `FirewallDBs` interface instead of the specific store implementation type.
During the upcoming upcoming migration of the firewall database to SQL, we need to be able to check all kvstores records in the SQL database, to validate that the migration is successful in tests. This commits adds a query to list all kvstores records, which enables that functionality.
Rename the session_id to group_id in kvstores table in the SQL store, to better represent how the field is actually used. Note that this is a breaking change, and would normally require a new migration. But as the SQL store is not used in production, and only enabled under the dev build flag, we can rename it without a new migration, as there's no users of the SQL store in production.
During the migration of the kvstores to SQL, we'll iterate over the buckets in the bbolt database, which holds all kvstores records. In order to understand why the migration iterates over the buckets in the specific order, we need to clarify the bbolt kvstores illustration docs, so that it correctly reflects how the records are actually stored in the bbolt database.
This commit introduces the migration logic for transitioning the kvstores store from kvdb to SQL. Note that as of this commit, the migration is not yet triggered by any production code, i.e. only tests execute the migration logic.
This commit updates litd to use the new sqldb v2 package. Note that this with just this commit, litd will not utilize the capabilities of sqldb v2 to run specific post migrations steps (such as migrating the kvdb to SQL). That functionality will be added in later commits. Instead, this commit just focuses on adding support for the new sqldb v2 package, and the functionality of the SQL stores are expected to remain the same as prior to this commit.
rename `sqlStore` to `store` in the firewalldb sql migration test file, to make the name shorted. This is done in preparation for future commits which will lengthen the lines where `sqlStore` is used, which otherwise would make the lines exceed the 80 character limit.
This commit introduces the `sqlcmig6` package, which at the time of this commit contains the same queries and models as `sqlc` package. Importantly though, once the kvdb to sql migration is made available in production, the `sqlcmig6` package will not change, as it is intended to represent the sql db as it was at the time of the migration. The sqlcmig6 package is therefore intended to be used in the kvdb to sql migration code, as it is will always be compatible with the sql database when all sql migrations prior to the kvdb to sql migration are applied. When additional sql migrations are added in the future, they may effect the `sqlc` package in such a way that the standard `sqlc` queries and models aren't compatible with kvdb to sql migration code any longer. By preserving the `sqlcmig6` package, we ensure that the kvdb to sql migration code can always use the same queries and models that were available at the time of the migration, even if the `sqlc` package changes in the future. Note that the `sqlcmig6` package have not been generated by `sqlc` (the queries and models are copied from the `sqlc` package), as it is not intended to be changed in the future.
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.
Summary of Changes
Hello @ViktorTigerstrom, 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 is a crucial step towards solidifying our database migration strategy. My primary goal is to decouple the KVDB to SQL migration process from ongoing schema evolution in the main application. By packaging the exact database queries and models used at the time of migration into a dedicated, versioned sqlcmig6
module, I'm ensuring that these critical historical migrations remain compatible and functional, regardless of future database changes. This also involves updating existing migration paths and refining our database interaction patterns for improved robustness and clarity.
Highlights
- Migration Stability: I've introduced a new
sqlcmig6
package. This package specifically contains thesqlc
generated queries and models exactly as they were at the time of the KVDB to SQL migration. This ensures that future changes to the mainsqlc
package won't break historical migration logic, providing long-term stability for the database migration process. - Migration Code Updates: The existing KVDB to SQL migration logic for accounts and sessions has been updated to utilize the newly introduced
sqlcmig6
package. This involves changing import paths, function signatures, and parameter types to align with the frozen schema and queries ofsqlcmig6
. - Database Abstraction Layer Refinement: The underlying database abstraction layer has been improved. This includes updating
db.BaseDB
tosqldb.BaseDB
, introducingSQLQueriesExecutor
andSQLMig6QueriesExecutor
for better query management, and standardizing transaction execution withsqldb.NoOpReset
across various store operations. This enhances flexibility and maintainability for different SQL backends. - KVStore Schema Evolution: The
kvstores
table schema has been updated to renamesession_id
togroup_id
. This change is reflected across thesqlc
generated code, SQL migration scripts, and related Go structs and functions, improving clarity and consistency in how session groups are referenced. - Firewall DB Migration Framework: A new migration framework for the
firewalldb
has been added, specifically for KV stores. This includes logic to collect data from the BoltDB, insert it into the SQL database usingsqlcmig6
types, and validate the migrated data, ensuring a robust transition for firewall-related data.
Using Gemini Code Assist
The 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 in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command>
or @gemini-code-assist <command>
. Below is a summary of the supported commands.
Feature | Command | Description |
---|---|---|
Code Review | /gemini review |
Performs a code review for the current pull request in its current state. |
Pull Request Summary | /gemini summary |
Provides a summary of the current pull request in its current state. |
Comment | @gemini-code-assist | Responds in comments when explicitly tagged, both in issue comments and review comments. |
Help | /gemini help |
Displays a list of available commands. |
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 .gemini/
folder in the base of the repository. Detailed instructions can be found here.
Limitations & Feedback
Gemini Code Assist is currently in preview and 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 to provide feedback.
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
-
Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩
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.
Code Review
This pull request introduces a snapshot of the database queries and models in a new sqlcmig6
package to ensure the stability of kvdb-to-SQL migrations against future schema changes. It also refactors the database layer to use the new lnd/sqldb/v2
package, centralizing migration and transaction logic. The changes are extensive and well-structured, including new migration logic for firewalldb
with thorough tests. My review found a couple of issues to address before this can be merged. Most critically, the go.mod
file contains replace
directives pointing to a personal fork and a local file path, which must be resolved. I also found a minor typo in a comment.
replace github.com/lightningnetwork/lnd => github.com/ViktorTigerstrom/lnd v0.0.0-20250710121612-a88fb038013b | ||
|
||
// TODO: replace this with your own local fork | ||
replace github.com/lightningnetwork/lnd/sqldb/v2 => ../../lnd_forked/lnd/sqldb |
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.
These replace
directives point to a personal fork and a local file path. While this is understandable for a draft PR that depends on unreleased changes, these must be removed and replaced with official releases before this PR can be merged. The local path in particular will break CI and prevent others from building the project.
|
||
// SQLMig6KVStoreQueries is a subset of the sqlcmig6.Queries interface that can | ||
// be used to interact with the kvstore tables. | ||
// |
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.
Based on and blocked by #1085
Implements step 2. of "Phase 3" in #917.
This is a draft PR that introduces a new sqlc package called
sqlcmig6
, which packages the exact SQL queries & models present at the time of the kvdb to sql migration. This PR then also updates the kvdb to sql migrations to use the queries & models from that package, instead of the standardsqlc
queries. This is required, as thesqlc
package, queries & models may change in such a way in the future, that they are no longer compatible with the kvdb to sql migrations, and we therefore need to enable functionality that runs the migrations with the exact queries & models present at the time of when the kvdb to sql migration was introduced.Note that this is only a draft PR for now, as the sqldb/v2 is not released, and we therefore need to add forked+local dependencies in order to run this. Once we have an official release of the sqldb/v2 package, I'll update this PR to use that dependency.