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

refactor: Decouple client.DB from net #2768

Conversation

fredcarle
Copy link
Collaborator

Relevant issue(s)

Resolves #2767

Description

This PR make the net package no longer dependent on client.DB. Instead, on creation, the peer takes in a rootstore, a blockstore and an event bus.

The p2p collections and replicators have been moved to db. Most of the code is reused but it now makes use of the event bus to update the peer's related state (pubsub topics and peer connections).

Tasks

  • I made sure the code is well commented, particularly hard-to-understand areas.
  • I made sure the repository-held documentation is changed accordingly.
  • I made sure the pull request title adheres to the conventional commit style (the subset used in the project can be found in tools/configs/chglog/config.yml).
  • I made sure to discuss its limitations such as threats to validity, vulnerability to mistake and misuse, robustness to invalidation of assumptions, resource requirements, ...

How has this been tested?

make test

Specify the platform(s) on which this was tested:

  • MacOS

@fredcarle fredcarle added refactor This issue specific to or requires *notable* refactoring of existing codebases and components area/p2p Related to the p2p networking system area/network Related to internal/external network components labels Jun 25, 2024
@fredcarle fredcarle added this to the DefraDB v0.12 milestone Jun 25, 2024
@fredcarle fredcarle requested a review from a team June 25, 2024 04:17
@fredcarle fredcarle self-assigned this Jun 25, 2024
Copy link

codecov bot commented Jun 25, 2024

Codecov Report

Attention: Patch coverage is 79.52030% with 111 lines in your changes missing coverage. Please review.

Project coverage is 78.95%. Comparing base (204c8ef) to head (44fd3c6).

Additional details and impacted files

Impacted file tree graph

@@             Coverage Diff             @@
##           develop    #2768      +/-   ##
===========================================
+ Coverage    78.75%   78.95%   +0.20%     
===========================================
  Files          315      315              
  Lines        23836    23873      +37     
===========================================
+ Hits         18771    18848      +77     
+ Misses        3685     3654      -31     
+ Partials      1380     1371       -9     
Flag Coverage Δ
all-tests 78.95% <79.52%> (+0.20%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files Coverage Δ
client/errors.go 59.32% <ø> (ø)
datastore/blockstore.go 76.92% <ø> (ø)
datastore/multi.go 90.91% <100.00%> (-9.09%) ⬇️
event/event.go 100.00% <ø> (ø)
internal/db/db.go 58.93% <100.00%> (-1.79%) ⬇️
internal/db/merge.go 86.34% <100.00%> (+7.89%) ⬆️
internal/merkle/clock/clock.go 69.33% <100.00%> (+2.67%) ⬆️
internal/merkle/crdt/composite.go 83.33% <100.00%> (ø)
internal/merkle/crdt/counter.go 66.67% <100.00%> (ø)
internal/merkle/crdt/lwwreg.go 75.00% <100.00%> (ø)
... and 14 more

... and 18 files with indirect coverage changes


Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 204c8ef...44fd3c6. Read the comment docs.

@fredcarle fredcarle force-pushed the fredcarle/refactor/node-store-dependency branch from d0dee58 to 8d01f2a Compare June 25, 2024 04:40
net/node_test.go Outdated Show resolved Hide resolved
Copy link
Member

@shahzadlone shahzadlone left a comment

Choose a reason for hiding this comment

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

suggestion: Also rename func (c *Client) Root() datastore.Rootstore { in http/client.go ?

Comment on lines +330 to +338
for _, rep := range replicators {
schemaMap := make(map[string]struct{})
for _, schema := range rep.Schemas {
schemaMap[schema] = struct{}{}
Copy link
Member

@shahzadlone shahzadlone Jun 25, 2024

Choose a reason for hiding this comment

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

suggestion: One liner comment on the nested for-loops will be handy IMO. Also is missing test coverage.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

The replicator event requires a map so we have to build it. Do we really need a comment for this?

Copy link
Contributor

Choose a reason for hiding this comment

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

What info are you looking for here Shahzad? I think a comment here would reduce the readability of the code

Copy link
Member

Choose a reason for hiding this comment

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

perhaps this is more personal pref, I like comments like: "convert to map for replicator event". But no biggie

@shahzadlone
Copy link
Member

I do like the changes but there seems to be a massive hit (-4%) to code coverage in this PR:

image

Copy link
Contributor

@islamaliev islamaliev left a comment

Choose a reason for hiding this comment

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

Looks great. Thanks for moving stuff around, this definitely improves the code quality. I just have few minor suggestions/concerns.

internal/db/errors.go Show resolved Hide resolved
Comment on lines +120 to +144
// P2PTopic is an event that is published when a peer has updated the topics it is subscribed to.
type P2PTopic struct {
ToAdd []string
ToRemove []string
}

// PeerInfo is an event that is published when the node has updated its peer info.
type PeerInfo struct {
Info peer.AddrInfo
}

// Replicator is an event that is published when a replicator is added or updated.
type Replicator struct {
// The peer info for the replicator instance.
Info peer.AddrInfo
// The map of schema roots that the replicator will receive updates for.
Schemas map[string]struct{}
// Docs will receive Updates if new collections have been added to the replicator
// and those collections have documents to be replicated.
Docs <-chan Update
}
Copy link
Contributor

Choose a reason for hiding this comment

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

suggestion: I already expressed my concern about having all possible events gathered here in event package here #2700 (comment).
This is a code-smell. event package should be responsible for sending, receiving, routing event, not on specific event types. It shouldn't event know about ipfs and libp2p.
The structs should go to places where they belong, for example, where the event are supposed to be fired.

I don't see any problem in defining these event in peer package. For example, with P2PTopic it's just db package that fires and listens to the event.

Copy link
Collaborator Author

@fredcarle fredcarle Jun 25, 2024

Choose a reason for hiding this comment

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

We can't. The type needs to be known by both the emitter and receiver. If they are defined in their respective "most appropriate" packages, we will end up with circular dependencies. This was already covered when Keenan introduced the change.

Copy link
Contributor

Choose a reason for hiding this comment

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

this just means that we have a problem with design and code structure. Moving stuff here is just another work-around.
2 packages can not be dependent of each other, that means whoever is independent can host the event definition.
But it's your call. I believe this PR is a good step towards cleaner code structure overall and I'm fine with keep the events here as a temporary solution. Would be nice to ticket though to keep track of our technical dept.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Here is an example of why I'm saying this. Right now all of the current events could be moved to the net package. Lets say though that we need to add one to the db package because it's a db specific event and net, amongst other packages, needs to know about that db event. We end up with a situation where net imports db and db imports net.

Copy link
Contributor

Choose a reason for hiding this comment

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

If we ever needed an event type to be shared between db and net, we should probably define that type in a third pacakge, probably core. I do agree with Islam that the generic events package should not be coupled to its usecases.

This coupling aside, events could be quite a handy package to use outside of the defra repo (like immutable).

@fredcarle Do you have any objections to defining them in core, or a sub-package of core?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Just to clarify, when I say everything I mean every event types. Not the bus implementation itself.

Copy link
Contributor

Choose a reason for hiding this comment

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

You don't picture us ever needing/wanting internal event types?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

If you mean that the public ones can be in client/event and the internal ones in internal/core/event or something like that then yes I think that's totally fine and probably desired.

Copy link
Contributor

Choose a reason for hiding this comment

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

Nice, Islam are you happy with this?

And if so, are you happy with re-orging the events into client/core in another PR (if that's what Fred prefers)? I do see moving them as out of scope here, and if I was the author would rather do it elsewhere.

Copy link
Contributor

@islamaliev islamaliev Jun 26, 2024

Choose a reason for hiding this comment

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

yeah, I'm fine with it, also with doing this in a separate PR.

internal/db/p2p_replicator_test.go Outdated Show resolved Hide resolved
internal/db/p2p_schema_root.go Outdated Show resolved Hide resolved
tests/integration/utils2.go Outdated Show resolved Hide resolved
tests/integration/db.go Outdated Show resolved Hide resolved
@fredcarle
Copy link
Collaborator Author

I do like the changes but there seems to be a massive hit (-4%) to code coverage in this PR:

That can't be right. I've seen that in an other PR lately as well. This one for example: #2748. I think it's a codcov bug.

@AndrewSisley
Copy link
Contributor

I do like the changes but there seems to be a massive hit (-4%) to code coverage in this PR:

That can't be right. I've seen that in an other PR lately as well. This one for example: #2748. I think it's a codcov bug.

A lot of the CI in this PR is failing atm, it might be caused by that (failing tests hopefully dont contribute to code coverage)

@fredcarle fredcarle force-pushed the fredcarle/refactor/node-store-dependency branch 2 times, most recently from 3bd9996 to e54c1ac Compare June 25, 2024 18:09
node/node.go Show resolved Hide resolved
@fredcarle fredcarle force-pushed the fredcarle/refactor/node-store-dependency branch from e2af1e9 to ae39093 Compare June 25, 2024 19:54
@fredcarle fredcarle force-pushed the fredcarle/refactor/node-store-dependency branch 8 times, most recently from 7a7de1b to 571cbc9 Compare June 27, 2024 17:09
Copy link
Contributor

@AndrewSisley AndrewSisley left a comment

Choose a reason for hiding this comment

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

LGTM, just one small todo - thanks Fred :)

internal/db/messages.go Show resolved Hide resolved
Copy link
Member

@shahzadlone shahzadlone left a comment

Choose a reason for hiding this comment

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

Looks good! Great work

@fredcarle fredcarle force-pushed the fredcarle/refactor/node-store-dependency branch from 571cbc9 to 0686be2 Compare July 1, 2024 22:48
@fredcarle fredcarle force-pushed the fredcarle/refactor/node-store-dependency branch from ab6f897 to 44fd3c6 Compare July 1, 2024 23:01
@fredcarle fredcarle merged commit ea77dc2 into sourcenetwork:develop Jul 1, 2024
38 of 39 checks passed
@fredcarle fredcarle deleted the fredcarle/refactor/node-store-dependency branch July 1, 2024 23:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/network Related to internal/external network components area/p2p Related to the p2p networking system refactor This issue specific to or requires *notable* refactoring of existing codebases and components
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Decouple client.DB from net
5 participants