[sql-57] Add accounts kvdb->SQL migration itest#1207
[sql-57] Add accounts kvdb->SQL migration itest#1207ViktorT-11 wants to merge 2 commits intolightninglabs:trigger-kvdb-to-sql-migfrom
Conversation
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 significantly advances the project's database infrastructure by introducing a robust integration test for the KVDB to SQL migration of the accounts store. It involves a comprehensive refactoring of the database interaction layer, adopting a new Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. 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
|
There was a problem hiding this comment.
Code Review
This pull request introduces the foundational components for testing KVDB to SQL migrations within the integration test framework, focusing on the accounts store. The changes are extensive, involving a significant refactoring of the database layer to align with lnd/sqldb/v2, introducing a dev build tag for migration-specific code, and adding a new integration test to validate the migration flow. The overall approach is solid and the new test provides valuable coverage. I have one minor suggestion for improving consistency.
| // DBFilename is the filename within the data directory which contains | ||
| // the macaroon stores. | ||
| DBFilename = "accounts.db" | ||
| DBFilename = "accounts.DB" |
This commit adds the foundational components for testing the kvdb -> SQL migration within the itest framework. The benefit of adding migration coverage through itests compared to just unit tests, is that this will test the full migration flow in litd, as it would be executed in production for a user who switches from a bbolt database backend to an SQL database backend. Additionally, as itests have access to the full litcli, we can also assert parts of the migration through litcli commands, as the end user would experience it.
Implement itest coverage for migrating account data from kvdb to sql. The itest coverage mimics the unit tests in accounts/sql_migration_test.go, except for the randomized migration tests. This coverage ensures that the full kvdb->SQL migration flow for litd works as expected for the accounts store.
5247a8d to
891a015
Compare
|
@ViktorT-11, remember to re-request review from reviewers when ready |
Based on #1114
Implements part of step 6. of "Phase 3" in #917.
This PR adds the foundational components for testing the kvdb -> SQL migration within the itest framework, and implements itest coverage for the migration of the accounts store.
I'll add follow up PRs which will also add implement itest coverage for the sessions store, and the full firewalldb store.
The benefit of adding migration coverage through itests compared to just unit tests, is that this will test the full migration flow in litd, as it would be executed in production for a user who switches from a bbolt database backend to an SQL database backend.
Additionally, as itests have access to the full litcli, we can also assert parts of the migration through litcli commands, as the end user would experience it.