Clean up hold_range_in_memory from accounts index: part 3#6920
Clean up hold_range_in_memory from accounts index: part 3#6920HaoranYi merged 1 commit intoanza-xyz:masterfrom
Conversation
57335da to
cc47227
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #6920 +/- ##
=========================================
- Coverage 83.2% 83.2% -0.1%
=========================================
Files 853 853
Lines 375491 375480 -11
=========================================
- Hits 312567 312522 -45
- Misses 62924 62958 +34 🚀 New features to boost your workflow:
|
55ce583 to
0118cad
Compare
| R: RangeBounds<Pubkey>, | ||
| { | ||
| #[cfg(feature = "dev-context-only-utils")] | ||
| pub fn items(&self) -> Vec<BucketItem<T>> { |
There was a problem hiding this comment.
Now this fn is only used in test. And we don't need to filter by range. so we can refactor it and put it in "dev-context-only-utils".
There was a problem hiding this comment.
It looks like theres one usage left? How hard would that be to remove?
There was a problem hiding this comment.
I think it is fine to keep it. It is only used in test and has been marked as "dev-context-only-utils". It won't be affecting validator binary.
There was a problem hiding this comment.
My thinking is more along the lines of:
If there is only one usage of this API and type, and it's in a test: Why is it needed at all?
Is the test in the end just in effect testing the API? Or if the test is testing something else, is there a better API it should be using.
There was a problem hiding this comment.
ah. no, the test code, where it is used, is not testing this API. fn items() is a test utility API. It is used as a way to assert the content of bucketmap is expected in testing other APIs, such as assert, delete etc.
d190442 to
ccab019
Compare
ccab019 to
7586322
Compare
Problem
hold_range_in_memory was originally introduced to support rent scanning by keeping certain key ranges in memory. However, since we no longer perform range-based rent scanning, this mechanism is now obsolete.
This is part 3 for the clean up: refactor bucket_api item_in_range.
Summary of Changes
Fixes #