-
Notifications
You must be signed in to change notification settings - Fork 77
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 keyrange #939
base: master
Are you sure you want to change the base?
Refactor keyrange #939
Conversation
@lxl66566 Convert your pr to draft since CI failed |
3ee8802
to
60f7fee
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #939 +/- ##
==========================================
- Coverage 75.55% 75.20% -0.36%
==========================================
Files 180 190 +10
Lines 26938 28625 +1687
Branches 26938 28625 +1687
==========================================
+ Hits 20353 21526 +1173
- Misses 5366 5791 +425
- Partials 1219 1308 +89 ☔ View full report in Codecov by Sentry. |
@lxl66566 Your PR is in conflict and cannot be merged. |
This PR is stale because it has been open for 30 days with no activity. Remove stale label or comment or this will be closed in 14 days |
60f7fee
to
30c4a69
Compare
30c4a69
to
020b290
Compare
@lxl66566 Convert your pr to draft since CI failed |
020b290
to
eed9a58
Compare
/// OneKey, to distinguish from `Prefix` because they all have [a, a+1) form | ||
OneKey(&'a [u8]), |
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.
A single key is ["a", "a\x00")
while a prefix should be ["a", "b")
. Why do we need a separate OneKey
variant?
/// Range end to get one key | ||
pub const ONE_KEY: &[u8] = &[]; | ||
|
||
pub trait Add1 { |
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.
Would it be more appropriate to name it Successor
?
Signed-off-by: lxl66566 <[email protected]> refactor(xlineapi): KeyRange refactor Signed-off-by: lxl66566 <[email protected]> refactor(xlineapi): refactor success, test pass Signed-off-by: lxl66566 <[email protected]> refactor(xlineapi): use KeyRange instead of directly pass &[u8] to avoid clone Signed-off-by: lxl66566 <[email protected]> refactor(xlineapi): simplify all keys judgement Signed-off-by: lxl66566 <[email protected]>
Signed-off-by: lxl66566 <[email protected]>
Signed-off-by: lxl66566 <[email protected]>
eed9a58
to
75cda98
Compare
This PR is stale because it has been open for 30 days with no activity. Remove stale label or comment or this will be closed in 14 days |
@lxl66566 Your PR is in conflict and cannot be merged. |
close #743
Please briefly answer these questions:
what problem are you trying to solve? (or if there's no problem, what's the motivation for this change?)
KeyRange
andInterval<BytesAffine>
, transform through &[u8]. This may make unnecessary Vec clone and memory allocation.KeyRange
is too confusing and troubling due to Bounds.what changes does this pull request make?
KeyRange
is refactored:EtcdKeyRange
andInterval<BytesAffine>
without cloning.Interval::overlap
.OneKey
andRange
is to distinguishprefix
andonekey
, which may has same form in [a, a+1).KeyRange
usage incrates/xline/src/storage/index.rs
andcrates/xline/src/storage/kv_store.rs
. By using KeyRange directly instead ofstart: &[u8], end: &[u8]
maybe better to construct from one key or all keys, and reduce the clone times.are there any non-obvious implications of these changes? (does it break compatibility with previous versions, etc)