[g175] graph/db: merge g175 types-prep side branch #10414
Conversation
Add a new migration that updates the graph tables (nodes, channels and policies) in preparation for the new columns required for V2 announcements. This migration has to be added to the set of "live" migrations instead of "dev only" since it edits the columns of existing tables and so changes the existing sql models. We are going to prep the SQLStore code to handle the V2 types in the coming commits, so we need this migration to be in place. In this commit we also remove the TestSchemaMigrationIdempotency test since this test fails with the new "ALTER TABLE" migrations which dont have "IF NOT EXISTS" options like tables and indexes do. Migrations should be idempotent anyways due to the migration tracker file and/or the sqlc migration tracker.
The underling store will store gossip messages across gossip versions and we will instead expose version parameters on many of the methods. So this interface really just abstracts the underlying store/schema type.
We add a new NewV2Node constructor which takes a new NodeV2Fields as a parameter. This NodeV2Fields struct defines the fields that can be set in a models.Node if the version is V2.
Here we update the UpdateNode query so that it can be used to insert the new blockheight field for a v2 node.
Instead of embedding Store in ChannelGraph so that any methods of the Store interface not implemented by the ChannelGraph are redirected to the underlying Store, we update things in this commit to instead make the "redirection" explicit. This is in preparation for changes we will make soon where some underlying store methods will take an explicit "version" parameter but then we will keep the ChannelGraph methods as is so that existing call-sites dont all need to be updated. We will then add "Versioned" ChannelGraph wrapper which decides the version use. Initially, most call-sites will just create a wrapped V1 ChannelGraph so that the logic remains as it is today.
Update the SQLStore node writer and readers to handle V2 ndoes. Currently no logic will actually add such nodes. The following commits will update what is needed so that CRUD for v2 nodes can be tested.
HasNode currently is very v1 specific since it returns a time.Time timestamp which is specific to V1 node announcements. However, it is mostly only used for the "exists" return value. So here we split it up into HasNode which just checks existence and HasV1Node which retains the same behavaiour as before.
Update some of the node related graph CRUD methods to take a version rather than hardcoding them in the SQLStore layer. Move the version up one layer instead. This will make it easier to make it configurable later on.
Add an isSQLDB variable that will let us quickly check in tests if the backing DB is KVStore or SQLStore.
For now, all instances will use V1 only so as not to change behaviour yet.
This will be used to run sub-tests with v2 data.
Convert a few more CRUD methods to handle v2 nodes. Then update some more tests to be run against both v1 and v2 nodes.
[g175:2] graph/db: v2 columns and v2 node CRUD
Summary of ChangesHello @ellemouton, 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 focuses on preparing the lightning network daemon's graph database for future compatibility with gossip version 2 nodes. It introduces necessary schema changes, code modifications, and a versioned graph structure to ensure a smooth transition and graceful handling of different gossip versions. The changes primarily affect the graph database layer and aim to enhance the system's ability to adapt to evolving network standards. 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
|
![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 is a significant refactoring to prepare the graph database for handling gossip V2 nodes. The core changes include renaming V1Store to Store, introducing a VersionedGraph wrapper to handle different gossip versions, and updating various parts of the codebase to use this new abstraction. The changes are well-structured and consistently applied. My review found a couple of minor style guide violations regarding the formatting of switch statements, for which I've provided suggestions.
This PR represents all the gossip 1.75 prs that have been merged into the
elle-g175Prep-basebranch. We can merge this PR into master once the type preparations are complete (ie, all the CRUD has been updated to handle the new v2 types).Merged
In Review
modelsfor V2 data #10379TODO