-
Notifications
You must be signed in to change notification settings - Fork 160
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
Implement TipIndex #113
Implement TipIndex #113
Conversation
* Restructured blockchain component into isolated crates * Added TipIndex methods * Initial store structures
* Added store struct with relevant fields * Added TipIndex structures with appropiate methods * Added unit tests for each of those methods * Added errors mod for chain crate
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.
breaking up the review, will look into the logical changes in another
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.
As some of the changes I suggested are a little more nuanced and repeated, I pushed some of the changes so it may be easier to follow. Feel free to copy if you agree with the changes (branch austin/tipisuggestions) dustin/tip-index...austin/tipisuggestions
@austinabell I have made the requested changes and reviewed your branch....thank you, much appreciated!! The two points:
I completely agree and I tried implementing a very generic approach as described in the PR dialogue. I will try to refactor to improve the redundancy today but open to suggestions/direction on how to accomplish.
Again agree and I made a comment about it in the PR dialogue on the different approach I looked at. Again I will try to refactor to improve but open to suggestions/direction on how to accomplish. |
The issue is that the HashTable cannot have multiple values for the key type, it must be one. What can be done is just making the key a u64 (what the hash resolves to anyway) and just use that to remove the need for putting and getting using the seperate hashmaps. I implemented on my flight because I got bored: dustin/tip-index...austin/tipindexsingle |
use cid::Cid; | ||
use network::service::NetworkMessage; | ||
|
||
pub struct _Store { |
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.
oh and you don't need to underscore prefix the struct, only the unused fields, this does nothing
Co-Authored-By: Austin Abell <austinabell8@gmail.com>
A couple of important notes:
You will see in the unit tests I am re-using the setup in
tipset.rs
to construct atipset
, again I explored a few approaches in order to just importsetup()
to avoid redundancy but could not get it to work since it's withinmod tests
intipset.rs
and pulling it out ofmod tests
would require pulling all dependant functions with it which is too messy. I also tried making these test setup functions into its own cratetest_utils
however, I ran into circular dependencies.Changes made in this PR:
TODO:
ChainReader
trait that makes use of these methods that can be shared across components for easy lookupsCloses #109