-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
[1/3] Graph RIP: refactor+graph: move all graph related DB code to the graph package #9236
Conversation
Important Review skippedAuto reviews are limited to specific labels. 🏷️ Labels to auto review (1)
Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
fee4ca7
to
2b3f659
Compare
8568ef5
to
5ae0c8a
Compare
b465402
to
1504b31
Compare
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.
Thanks for taking the care to make such iterative commits, extremely easy to read and reason about❤️ I think this is almost good to go, just a few questions.
AddrsForNode(nodePub *btcec.PublicKey) ([]net.Addr, error) | ||
// key. The returned boolean must indicate if the given node is unknown | ||
// to the backing source. | ||
AddrsForNode(nodePub *btcec.PublicKey) (bool, []net.Addr, error) |
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.
not sure about the last bool
since the caller can know if this is known or not by checking the error? But I guess it's nice to have this abstraction so the caller doesn't need to care about the specific errors. Curious about what others think.
On the other hand, if we decide to use the intersection instead of the union of the sets, we can then remove this bool.
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.
since the caller can know if this is known or not by checking the error
Not necessarily since there are possibly multiple backends. The caller should not need to know to check both graphdb.NotFound
and channeldb.NotFound
.
ut I guess it's nice to have this abstraction so the caller doesn't need to care about the specific errors.
yeah exactly
if we decide to use the intersection instead of the union of the sets, we can then remove this bool.
I think we want the union though for maximum address coverage. The reason we check multiple sources is so that we have a higher probability of using a more up to date address
lncfg/db.go
Outdated
@@ -47,6 +49,8 @@ const ( | |||
// and channel state DB. | |||
NSChannelDB = "channeldb" | |||
|
|||
NSGraphDB = "graphdb" |
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.
niiiice - guess we can do a followup PR to implement this and migrations? Think the migration might be huge tho.
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.
i think we might actually not need to ever migrate this since: with the Gossip V2 upgrade, we will start using SQL for new messages & we will start using SQL for legacy channels advertised with the new protocol. So eventually, all the channels in the v1 DB should become zombies as the network migrates to V2 and at that point, we can just delete that DB.
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.
Think that would take years🤔
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.
yeah indeed. so yeah maybe we will end up doing a migration (maybe directly to SQL land) in a follow up.
|
||
// AddrsForNode returns all known addresses for the target node public key. | ||
// | ||
// NOTE: this implements the AddrSource interface. |
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.
could mention that we are using the union of the sets instead of the intersection. And also have a question here - if the node is not found in either DB, does it mean there's a bug somewhere? If it's not in the link db, think the node cannot be used for sending htlcs. when it's not in the graph db, it won't be used for pathfinding.
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.
could mention that we are using the union of the sets instead of the intersection
updated 👍
And also have a question here - if the node is not found in either DB, does it mean there's a bug somewhere? If it's not in the link db, think the node cannot be used for sending htlcs. when it's not in the graph db, it won't be used for pathfinding.
perhaps - but i think that is for the layer making the call to decide.
6a99e77
to
bc76c5b
Compare
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.
Thanks @yyforyongyu 🙏 updated!
|
||
// AddrsForNode returns all known addresses for the target node public key. | ||
// | ||
// NOTE: this implements the AddrSource interface. |
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.
could mention that we are using the union of the sets instead of the intersection
updated 👍
And also have a question here - if the node is not found in either DB, does it mean there's a bug somewhere? If it's not in the link db, think the node cannot be used for sending htlcs. when it's not in the graph db, it won't be used for pathfinding.
perhaps - but i think that is for the layer making the call to decide.
AddrsForNode(nodePub *btcec.PublicKey) ([]net.Addr, error) | ||
// key. The returned boolean must indicate if the given node is unknown | ||
// to the backing source. | ||
AddrsForNode(nodePub *btcec.PublicKey) (bool, []net.Addr, error) |
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.
since the caller can know if this is known or not by checking the error
Not necessarily since there are possibly multiple backends. The caller should not need to know to check both graphdb.NotFound
and channeldb.NotFound
.
ut I guess it's nice to have this abstraction so the caller doesn't need to care about the specific errors.
yeah exactly
if we decide to use the intersection instead of the union of the sets, we can then remove this bool.
I think we want the union though for maximum address coverage. The reason we check multiple sources is so that we have a higher probability of using a more up to date address
lncfg/db.go
Outdated
@@ -47,6 +49,8 @@ const ( | |||
// and channel state DB. | |||
NSChannelDB = "channeldb" | |||
|
|||
NSGraphDB = "graphdb" |
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.
i think we might actually not need to ever migrate this since: with the Gossip V2 upgrade, we will start using SQL for new messages & we will start using SQL for legacy channels advertised with the new protocol. So eventually, all the channels in the v1 DB should become zombies as the network migrates to V2 and at that point, we can just delete that DB.
e017ccf
to
ce32340
Compare
just resolving merge conflicts :) |
4d25e70
to
a9eea37
Compare
Added a commit (multi: rename chan DB Open method to OpenForTesting) as suggested by @guggero 🙏 Only affects testing code |
a9eea37
to
ec8a0be
Compare
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.
Amazing PR 💯
I think we can remove the last commit (TEMP
) and merge 🚀
We'll move these to the new graphdb package later and import them from there.
In preparation for moving the graph related schema structs to the graph package in an upcoming commit, we move these methods to the graph package. The structs we will move make use of these methods but we still import them from channeldb so as to keep the ReadElement and WriteElement helpers working as they do today.
We have the same helpers for writing and reading a wire.Outpoint type defined separately in a couple places. We will want to use these from the graph db package soon though so instead of defining them again there, this commit unifies things and creates a single exported set of helpers. The next commit will make use of these.
Start using the single set of exported write/read functions for wire.Outpoint.
All the structs defined in the `channeldb/models` package are graph related. So once we move all the graph CRUD code to the graph package, it makes sense to have the schema structs there too. So this just moves the `models` package over to `graph/db/models`.
This is a pure refactor commit. It moves over all the graph related CRUD code from `channeldb` to `graph/db`.
We also now use the graph DB's own optional functions. An instance of the graph is currently still passed to the channeldb's `CreateWithBackend` function. This will be removed in a later commit once the two have been completely disjoint.
Our aim is to completely remove the `channeldb.DB`'s direct dependence on the `graphdb.ChannelGraph` pointer. The only place where it still depends on this pointer is in the `(DB).AddrsForNode(..)` method where it queries both the channel DB and the graph db for the known addresses for the node in question and then combines the results. So, to separate these out, we will define an AddrsForNodes interface in this commit which we will later let both the ChannelGraph and channeldb.DB both implement and we will merge these results outside of the channeldb package. All this commit does is to unify the `AddrSource` interface since this has been defined separately in a couple of places.
In this commit, we implement a version of the AddrSource interface which merges the results of a set of AddrSource implementations. This will later be used to merge the results of the channel db and graph db.
Before this commit, the `(channeldb.DB).AddrsForNode` method treats the results from the channel db and the graph db slightly differently. It errors out if the channel db is unaware of the node in question but does not error out if the graph is unaware of the node. So this commit changes the logic slightly so that a "node-unknown" error from either backing source is not seen as an error.
Then use both to construct a multiAddrSource AddrSource and use that around the code-base.
Now that the channel.DB no longer uses the ChannelGraph pointer, we can completely remove it as a member of channeldb.DB.
and the same for ChannelStateDB.FetchChannel. Most of the calls to these methods provide a `nil` Tx anyways. The only place that currently provides a non-nil tx is in the `localchans.Manager`. It takes the transaction provided to the `ForAllOutgoingChannels` callback and passes it to it's `updateEdge` method. Note, however, that the `ForAllOutgoingChannels` call is a call to the graph db and the call to `updateEdge` is a call to the `ChannelStateDB`. There is no reason that these two calls need to happen under the same transaction as they are reading from two completely disjoint databases. And so in the effort to completely split untangle the relationship between the two databases, we now dont use the same transaction for these two calls.
So that this fails earlier on if the actual call to UpdateChannelPolicy fails.
ec8a0be
to
54dbaa6
Compare
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.
Thanks @guggero! addressed comments and dropped the [TEMP] commit :)
This PR is part of the larger graph separation & gossip updates projects
This PR is mostly a refactor:
channeldb
and intograph/db
.ChannelGraph
fromchanneldb.DB
. The only place where the two are used together is forAddrSource
, so a couple of commits extract this.TEMP
) uses different files/DBs for the graph and channeldb. This is just to demonstrate the clean separation of the two. It is for reviewer confirmation of CI only & will be removed before merge.Part of #8833