Skip to content
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

Merged

Conversation

ellemouton
Copy link
Collaborator

@ellemouton ellemouton commented Oct 26, 2023

Overview

Today, the channeldb.LightningNode, channeldb.ChannelEdgePolicy and
channeldb.ChannelEdgeInfo objects all carry a kvdb.Backend pointer.
Additionally, the ChannelEdgePolicy has a channeldb.LightningNode
member.

This PR is a move towards making the above mentioned channeldb structs
more closely represent the on-disk schemas and does this by removing the
need for them to carry around the kvdb.Backend pointer and also removes
the need for channeldb.ChannelEdgeInfo to contain a
channeldb.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.

@ellemouton ellemouton mentioned this pull request Oct 26, 2023
21 tasks
@Roasbeef Roasbeef requested review from bhandras and Crypt-iQ October 26, 2023 17:55
@Roasbeef Roasbeef added this to the v0.18.0 milestone Oct 26, 2023
@ellemouton ellemouton force-pushed the removeDBFromChannelDBSchemas branch from daf6a5d to c9a27a9 Compare October 27, 2023 06:10
@ellemouton
Copy link
Collaborator Author

realised that with this change we can actually move the ChannelEdgeInfo, ChannelEdgePolicy, ChannelAuthProof and CachedEdgePolicy structs to the channeldb/models package instead.

Lemme know what you guys think & then I'll add a commit on.

Copy link
Collaborator

@bhandras bhandras left a 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,
Copy link
Collaborator

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?

Copy link
Collaborator Author

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?

Copy link
Collaborator

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.

Copy link
Collaborator Author

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 {
Copy link
Collaborator

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.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah yes - good catch

// 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.
Copy link
Collaborator

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)
Copy link
Collaborator

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

@bhandras
Copy link
Collaborator

realised that with this change we can actually move the ChannelEdgeInfo, ChannelEdgePolicy, ChannelAuthProof and CachedEdgePolicy structs to the channeldb/models package instead.

Lemme know what you guys think & then I'll add a commit on.

realised that with this change we can actually move the ChannelEdgeInfo, ChannelEdgePolicy, ChannelAuthProof and CachedEdgePolicy structs to the channeldb/models package instead.

Lemme know what you guys think & then I'll add a commit on.

What would be the benefit of this move?

channeldb/graph_test.go Outdated Show resolved Hide resolved
channeldb/graph.go Outdated Show resolved Hide resolved
channeldb/graph.go Outdated Show resolved Hide resolved
@lightninglabs-deploy
Copy link

@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.
@ellemouton ellemouton force-pushed the removeDBFromChannelDBSchemas branch from c9a27a9 to 4c3252d Compare November 8, 2023 09:25
@ellemouton
Copy link
Collaborator Author

What would be the benefit of this move?

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 :)

@ellemouton ellemouton force-pushed the removeDBFromChannelDBSchemas branch 2 times, most recently from 8b0eaea to 0ff271b Compare November 8, 2023 10:08
Copy link
Collaborator

@bhandras bhandras left a 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,
Copy link
Collaborator

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.

@bhandras
Copy link
Collaborator

bhandras commented Nov 8, 2023

What would be the benefit of this move?

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 :)

I like the change, slimming channeldb always makes sense :)

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.
@ellemouton ellemouton force-pushed the removeDBFromChannelDBSchemas branch from 0ff271b to 0e82293 Compare November 8, 2023 12:50
Copy link
Collaborator

@Crypt-iQ Crypt-iQ left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 🎲

@ellemouton ellemouton added this pull request to the merge queue Nov 8, 2023
@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to Branch Protection failures Nov 8, 2023
You're not authorized to push to this branch. Visit "About protected branches" for more information.
@ellemouton ellemouton merged commit 6122452 into lightningnetwork:master Nov 9, 2023
24 of 25 checks passed
@ellemouton ellemouton deleted the removeDBFromChannelDBSchemas branch November 9, 2023 05:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

6 participants