-
Notifications
You must be signed in to change notification settings - Fork 44
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
feat: Persist p2p replicators #960
feat: Persist p2p replicators #960
Conversation
Codecov Report
@@ Coverage Diff @@
## develop #960 +/- ##
===========================================
- Coverage 59.83% 57.11% -2.73%
===========================================
Files 160 164 +4
Lines 17724 19020 +1296
===========================================
+ Hits 10605 10863 +258
- Misses 6165 7173 +1008
- Partials 954 984 +30
|
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've added a few comments (all fairly localized) - I've not finished the peer.go stuff though as my brain is slowing down and I'm fairly unfamiliar with this part of the codebase
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.
Looks good Fred - a few localized comments, but it makes sense (I think 😁).
client/db.go
Outdated
@@ -39,6 +40,10 @@ type DB interface { | |||
Events() events.Events | |||
|
|||
PrintDump(ctx context.Context) error | |||
|
|||
AddReplicator(ctx context.Context, rep Replicator) 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.
thought: It might be nice if anything persisted via these calls gets automagically picked up by the P2P code (mid run, not just on restart), have you had any thoughts around that?
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'm not sure I understand what you are saying here. When a call to add replicator is received, the replicator is immediately picked up.
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.
It is? It looked like db.AddReplicator only persists the replicator config to store, and the peer code only ever checks the store for saved configs on defra startup?
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.
If it was as you say the tests wouldn't pass :)
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.
😁 Which bit am I misunderstanding? The peer stuff will pick up new stuff in the db (polling?)?
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.
The entry point when adding a replicator is line 280 in net/peer.go
. If you start there you'll have a clearer view of what is happening.
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 but that is what I mean - client.DB is a public interface, and users are free to call these members as and when they like. This function signature suggests (albeit much less so after renaming) that calling Add/SetReplicator would cause it to be active (and picked up auto magically by the peer code).
It would be nice if it did this at some point in the future.
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'm not sure I agree here. The functionality is available from the peer and the method should be called from peer. Nothing guarantees that peer exists and the interactions with the db are only to operate on the datastore.
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.
Ideally these methods would be internal. But that might be a change for future me lol.
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.
😁 That would also solve this lol
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.
Actually, I can approve as the only todos I added ask for documentation (if you dont want changes)
|
||
err = db.AddReplicator(ctx, client.Replicator{ | ||
Info: *info, | ||
Schemas: []string{"test", "test2", "test3"}, |
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.
question: If we have an already existing test
schema for the same info
then it is just ignored or overwritten in a way?
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.
If will be ignored. It's a cumulative add to ensure the user doesn't to remember all schemas that are replicated in order to just add one.
df313d1
to
2ba7fdf
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 the changes.
Relevant issue(s) sourcenetwork#462 sourcenetwork#955 sourcenetwork#954 sourcenetwork#952 Description This PR adds the ability to persist P2P replicators. It change to RPC part of the CLI to have a new sub command which is replicator. Using that sub command, we can add, delete and getAll to operate on the replicator store. Note: Using the config file to add replicators will be done in a future PR. Will most likely add integration test before merging this PR.
Relevant issue(s)
Resolves #462
Resolves #955
Resolves #954
Resolves #952
Description
This PR adds the ability to persist P2P replicators. It change to RPC part of the CLI to have a new sub command which is
replicator
.Using that sub command, we can
add
,delete
andgetAll
to operate on the replicator store.Note: Using the config file to add replicators will be done in a future PR. Will most likely add integration test before merging this PR.
Tasks
How has this been tested?
manual tests
Specify the platform(s) on which this was tested: