[typed store] iterators: deprecate skip_to/skip_prior_to/skip_to_last/reverse methods #21289
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
2 Skipped Deployments
|
phoenix-o
temporarily deployed
to
sui-typescript-aws-kms-test-env
GitHub Actions
Inactive
phoenix-o
force-pushed
the
db_iterators_interface_0
branch
from
d8c3193 to
81f33e7
Compare
phoenix-o
temporarily deployed
to
sui-typescript-aws-kms-test-env
GitHub Actions
Inactive
phoenix-o
changed the title
phoenix-o
temporarily deployed
to
sui-typescript-aws-kms-test-env
GitHub Actions
Inactive
| /// Upper bound is included. | ||
| pub fn reversed_safe_iter_with_bounds( | ||
| &self, | ||
| lower_bound: Option<K>, |
There was a problem hiding this comment.
I see there is two approaches in DBMap for bounds - there is either Option<> where Some(...) means included bound, and there is approach in range_iter and create_read_options_with_range method where user can select type of bounds to be either included or excluded.
Should we try to just adopt same style API for reverse iterator and name method reverse_range_iter? (e.g. allow user to select type of bounds). Especially since it looks like we are calling create_read_options_with_range internally anyway.
There was a problem hiding this comment.
maybe, we can further simplify and merge methods. We can do it as a followup though. This PR is already large/risky enough
Description
deprecates skip_to/skip_prior_to/skip_to_last/reverse methods
Release notes
Check each box that your changes affect. If none of the boxes relate to your changes, release notes aren't required.
For each box you select, include information after the relevant heading that describes the impact of your changes that a user might notice and any actions they must take to implement updates.