Combine (re)sharding hash rings in a single type, update split-by-shard logic #4236
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Tracked in #4213.
This combines (re)sharding hash rings in a single type, replacing the single hash ring we had before. It provides a consistent interface for all scenarios, whether we have a single hash ring or multiple while resharding. It keeping most of the existing logic intact, and allows us to extend and/or tweak behavior in a single place in the future.
Here I propose to replace the initial approach with a separate hash ring on a shared resharding key introduced in #4216. It seems more future proof, easier to manage, and remains on the shard key level. When working with shards, we always namespace to a specific shard key and so it makes sense to combine all necessary state in a single type with a single lookup.
It doesn't only replace the way of storing a resharding hash ring, but also updates all point-to-shard routing to spread to two shards in case of resharding.
All Submissions:
dev
branch. Did you create your branch fromdev
?New Feature Submissions:
cargo +nightly fmt --all
command prior to submission?cargo clippy --all --all-features
command?