-
Notifications
You must be signed in to change notification settings - Fork 353
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
Make Bound
s type safe
#462
Comments
A simple way to improve here would be to provide more helpers over So that, instead of something like .range(
&store,
Some(Bound::inclusive((U64Key::new(0), "").joined_key())),
Some(Bound::exclusive((U64Key::new(2), "").joined_key())),
Order::Ascending,
) the user can write instead .range(
&store,
(U64Key::new(0), "").inclusive_bound(),
(U64Key::new(2), "").exclusive_bound(),
Order::Ascending,
) This looks better. It requires knowledge of the key structure, but this info is public already. This is still not type-safe, in that the bound is still over From there, making these type-safe (i. e. building Need to think more about this, but it looks achievable. All this means, more "boiler plate" code on our side. But definitely, a better / safer user experience. |
A simpler alternative would be to provide helpers over Update: It turns out those helpers are already there(!) So, the issue here would be to enforce the use of the helpers. i.e. to prevent or discourage calling The limitation of this approach is that its |
This is a nice idea. I would like to highlight it for 0.12.0 storage-plus improvements. |
Current
Bound
s take aVec<u8>
as parameter, which is not related to the types the bound will apply to. This forces the user to build the proper bound manually, which requires knowledge of the internal structure used to store the different types. This is particularly annoying with composite keys, where a helper (joined_key
) must be used to concatenate the key components.Let's improve on this by making
Bound
type-safe. This may be tricky to do, as currentlyBound
is independent of the map-like structure it can be applied to.There's a
key()
(index_key
in the case if indexed maps) method in map-like structs, that can be used as an alternative to building the key manually. But, it only supports the full key, not the prefix / sub-prefix keys. An alternative could be to extend this with a couple ofprefix_key()
andsub_prefix_key()
helpers.Let's evaluate first if we can do better than that.
The text was updated successfully, but these errors were encountered: