-
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
channeldb+refactor: remove kvdb.Backend
from channel DB schemas
#8117
channeldb+refactor: remove kvdb.Backend
from channel DB schemas
#8117
Conversation
daf6a5d
to
c9a27a9
Compare
realised that with this change we can actually move the Lemme know what you guys think & then I'll add a commit on. |
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.
Nice refactor! LGTM 🎉
if ep == nil { | ||
return nil | ||
} | ||
return d.db.ForEachNodeChannel(d.tx, d.node.PubKeyBytes, |
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 wonder if there's a specific reason to not use pointer receivers for dbNode
methods?
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.
no idea 🤔 i can add a commit to try change it if you'd like?
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 I think it's probably cleaner to use pointer receivers, it's also just a small cleanup not really inflating the PR so feel free to add if you agree.
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.
cool - added a commit after this one :)
rpcserver.go
Outdated
return nil | ||
}); err != nil { | ||
return nil | ||
}); err != nil { |
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.
nit: maybe it's just the weird diff but formatting seems a bit off.
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.
ah yes - good catch
channeldb/graph.go
Outdated
// this pointer the channel graph can further be traversed. | ||
Node *LightningNode | ||
// ToNode is the public key of the node that this directed edge leads | ||
// to. Using this pointer the channel graph can further be traversed. |
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.
nit: "Using this pointer" => "Using this pubkey".
@@ -104,6 +104,11 @@ func (d dbNode) ForEachChannel(cb func(ChannelEdge) error) error { | |||
return nil | |||
} | |||
|
|||
node, err := d.db.FetchLightningNode(tx, ep.ToNode) |
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.
nit: in commit message: frmo => from, exaclty => exactly
What would be the benefit of this move? |
@ellemouton, remember to re-request review from reviewers when ready |
Having a `ForEachChannel` method on the `LightningNode` struct itself results in a `kvdb.Backend` object needing to be stored within the LightningNode struct. In this commit, this method is replaced with a `ForEachNodeChannel` method on the `ChannelGraph` struct will perform the same function without needing the db pointer to be stored within the LightningNode. This change, the LightningNode struct more closely represents the schema on disk. The existing `ForEachNodeChannel` method on `ChannelGraph` is renamed to `ForEachNodeDirectedChannel`. It performs a slightly different function since it's call-back operates on Cached policies.
c9a27a9
to
4c3252d
Compare
Basically just to continue to separate out schema from DB fetching/setting logic. Some packages only need the schemas & so dont need to import the entire channeldb package. I tacked on a commit at the end that does the move - lemme know if you think it makes sense - otherwise, im happy to drop it for now too :) |
8b0eaea
to
0ff271b
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.
LGTM 🥇
if ep == nil { | ||
return nil | ||
} | ||
return d.db.ForEachNodeChannel(d.tx, d.node.PubKeyBytes, |
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 I think it's probably cleaner to use pointer receivers, it's also just a small cleanup not really inflating the PR so feel free to add if you agree.
I like the change, slimming |
Now that the kvdb.Backend is no longer required, it is removed from the LightningNode struct.
To prepare for the `kvdb.Backend` member of `ChannelEdgeInfo` being removed, the `FetchOtherNode` method is moved from the `ChannelEdgeInfo` to the `ChannelGraph` struct.
In preparation for the next commit which will remove the `*LightningNode` from the `ChannelEdgePolicy` struct, `FetchLightningNode` is modified to take in an optional transaction so that it can be utilised in places where a transaction exists.
Finally, The LightningNode object is removed from ChannelEdgePolicy. This is a step towards letting ChannelEdgePolicy reflect exactly the schema that is on disk. This is also nice because the `Node` object is not necessarily always required when the ChannelEdgePolicy is loaded from the DB, so now it only get's loaded when needed.
This commit moves the ChannelEdgePolicy, ChannelEdgeInfo, ChanelAuthProof and CachedEdgePolicy structs to the `channeldb/models` package.
0ff271b
to
0e82293
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.
LGTM 🎲
Overview
Today, the
channeldb.LightningNode
,channeldb.ChannelEdgePolicy
andchanneldb.ChannelEdgeInfo
objects all carry akvdb.Backend
pointer.Additionally, the
ChannelEdgePolicy
has achanneldb.LightningNode
member.
This PR is a move towards making the above mentioned
channeldb
structsmore closely represent the on-disk schemas and does this by removing the
need for them to carry around the
kvdb.Backend
pointer and also removesthe need for
channeldb.ChannelEdgeInfo
to contain achanneldb.LightningNode
.Why?
For the Gossip 1.75 epic, it will be required to create abstractions of the mentioned
objects and so in order to avoid requiring interface methods like "GetDB()" and
"SetDB()", removing the db entirely from the objects will make for much simpler code.
I think this might also be useful for when we migrate channeldb to the sql world.