pippellia on Nostr: First of all, thanks for taking the time to look into it :) > i'd need you to specify ...
First of all, thanks for taking the time to look into it :)
> i'd need you to specify the packages and types and functions that you want me to review specifically, i mean, it all looks fairly routine worker loops with channel listener, context done and so forth
I am glad it looks fairly routine, as that was my goal since I've started using Go just 3 months ago.
> also the Database interface is huge, i think it should be broken into several smaller specific interfaces.
This is exactly the high-level feedback I am more interested in, thanks! Yes, the Database and RandomWalkStore interfaces are huge. First of all, do u think they should be interfaces at all? I've taken this approach for separating testing from performance optimization.
I first test that the algorithm and the data structures work together (e.g. the walks have the correct statistical distribution, and the algorithm uses that distribution correctly). For this purpose I found useful and quicker to use in-memory database mocks. The thing is that I need to tests on several graphs, and produce a big number of walks. Doing that on Redis without having it optimized will take a lot of time per test, possibly minutes.
By using mocks to test I reduced that to seconds. Once it works, I can test it with redis and optimize the perfomance.
The tradeoff is that I am testing on something that is not the production code but a mock, which also requires work to be maintained and so on.
Secondly, how would you split the interface?
The first idea that comes to mind is to have a DatabaseReader that has NodeByID, NodeByKey, NodeIDs, Pubkeys, Follows, Followers methods.
a DatabaseWriter that has AddNode and Update
a DatabaseScanner that has ScanNodes and AllNodes
Do u think this would be better?
> i'd need you to specify the packages and types and functions that you want me to review specifically, i mean, it all looks fairly routine worker loops with channel listener, context done and so forth
I am glad it looks fairly routine, as that was my goal since I've started using Go just 3 months ago.
> also the Database interface is huge, i think it should be broken into several smaller specific interfaces.
This is exactly the high-level feedback I am more interested in, thanks! Yes, the Database and RandomWalkStore interfaces are huge. First of all, do u think they should be interfaces at all? I've taken this approach for separating testing from performance optimization.
I first test that the algorithm and the data structures work together (e.g. the walks have the correct statistical distribution, and the algorithm uses that distribution correctly). For this purpose I found useful and quicker to use in-memory database mocks. The thing is that I need to tests on several graphs, and produce a big number of walks. Doing that on Redis without having it optimized will take a lot of time per test, possibly minutes.
By using mocks to test I reduced that to seconds. Once it works, I can test it with redis and optimize the perfomance.
The tradeoff is that I am testing on something that is not the production code but a mock, which also requires work to be maintained and so on.
Secondly, how would you split the interface?
The first idea that comes to mind is to have a DatabaseReader that has NodeByID, NodeByKey, NodeIDs, Pubkeys, Follows, Followers methods.
a DatabaseWriter that has AddNode and Update
a DatabaseScanner that has ScanNodes and AllNodes
Do u think this would be better?