-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Conversation
/// Remove all values of the storage in the overlay and up to `limit` in the backend. | ||
/// |
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.
Its just a crazy api. This is absolutely not an "expected" behavior, and we shouldn't really expose such weird things in this way...
We need apis like this which are both bounded and behave in expected ways.
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.
yes I agree, IMO we should at least have sp_io::storage::clear_prefix return the exact number of value removed (in both overlay and backend).
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.
seems like we need this right away, but hopefully this is not the final state of things
/// | ||
/// This function should never be called in production settings because it can lead to an | ||
/// unbounded amount of storage accesses. | ||
fn clear(); |
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.
Maybe call this unsafe_clear
then? To make the user aware of the problems?
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.
also in pallet-bags-list when implementing the function SortedListProvider::regenerate
it calls clear
inside. Should we also prepend unsafe to regenerate ? WDYT @kianenigma
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.
Yes we should
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.
addressed in fede886
Um... Does this means |
remove_all for counted storage map doesn't allow to give bounds on the number of value to remove from backend, thus in case you remove too many keys, this can go beyond PoV size. Also benchmarks should already count the number of storage access in general. |
Ok. So as long as we correctly benchmark all the calls using remove_all we should be mostly fine. |
bot merge |
Error: Approval by "Project Owners" is only attempted if other means defined in the criteria for merge are not satisfied first. The following errors might have affected the outcome of this attempt:
Merge failed. Check out the criteria for merge. If you're not meeting the approval count, check if the approvers are members of substrateteamleads or core-devs. |
companion needs a review |
reminder on this one |
bot merge |
Waiting for commit status. |
Merge cancelled due to error. Error: Companion paritytech/polkadot#4306 has error: Checks failed for bfccb973507ebc8d3a28a514e6a8f38073216fdb |
bot merge |
* fix bags list * improve doc * doc * inner doc * fix test * Update docs in frame/election-provider-support/src/lib.rs * fix staking impl * prepend unsafe to clear and regenerate * fix test Co-authored-by: Keith Yeung <kungfukeith11@gmail.com> Co-authored-by: Shawn Tabrizi <shawntabrizi@gmail.com>
* fix bags list * improve doc * doc * inner doc * fix test * Update docs in frame/election-provider-support/src/lib.rs * fix staking impl * prepend unsafe to clear and regenerate * fix test Co-authored-by: Keith Yeung <kungfukeith11@gmail.com> Co-authored-by: Shawn Tabrizi <shawntabrizi@gmail.com>
with current sp-io storage API we can't know how much we deleted when calling sp_io::storage::clear_prefix.
This information was not in the doc of
remove_all
function in frame-support., this is fixed.This was misused in pallet-bags-list, this is fixed too.
polkadot companion: paritytech/polkadot#4306
skip check-dependent-cumulus