Skip to content
This repository has been archived by the owner on Nov 15, 2023. It is now read-only.

BoundedVec + Shims for Append/DecodeLength #8556

Merged
20 commits merged into from
Apr 16, 2021
Merged

BoundedVec + Shims for Append/DecodeLength #8556

20 commits merged into from
Apr 16, 2021

Conversation

kianenigma
Copy link
Contributor

@kianenigma kianenigma commented Apr 7, 2021

impl<T: ValueType, S: Get<usize>, V: generator::StorageValue<BoundedVec<T, S>>> TryAppend<T, S>
for V
{
fn try_append<LikeT: EncodeLike<T>>(item: LikeT) -> Result<(), ()> {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, though eventually we'll probably want this to become a DispatchError to avoid a lot of .map_err(|()| Error::<T>::ItemOverflow)s.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure which variant it should be? Other or a new (general)Overflow would be okay, but the benefit of .map_err(|()| Error::<T>::ItemOverflow) is actually that we know from which pallet it is coming from.

@kianenigma kianenigma marked this pull request as ready for review April 8, 2021 08:15
@github-actions github-actions bot added the A0-please_review Pull request needs code review. label Apr 8, 2021
@kianenigma kianenigma added B0-silent Changes should not be mentioned in any release notes C1-low PR touches the given topic and has a low impact on builders. labels Apr 8, 2021
Copy link
Contributor

@apopiak apopiak left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cool addition!

frame/support/src/storage/mod.rs Outdated Show resolved Hide resolved
@shawntabrizi shawntabrizi added the D5-nicetohaveaudit ⚠️ PR contains trivial changes to logic that should be properly reviewed. label Apr 8, 2021
/// As the name suggests, the length of the queue is always bounded. All internal operations ensure
/// this bound is respected.
#[derive(Encode, Decode, crate::DefaultNoBound, crate::CloneNoBound, crate::RuntimeDebugNoBound)]
pub struct BoundedVec<T: Value, S: Get<u32>>(Vec<T>, sp_std::marker::PhantomData<S>);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess that this is using a type number with Get<u32> instead of a const generic because we don't want to raise the min supported rust version to 1.51?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually it probably can, I just didn't think about it :D Will try

because we don't want to raise the min supported rust version to 1.51?

I am pretty sure we always require latest stable version and don't care much about older versions.

Copy link
Contributor Author

@kianenigma kianenigma Apr 12, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

errr -- no.

I don't think we can make this configurable to the end-user, as it is now, with const generics. See how it is done in #8580.

We can, only if we swap things like type MaxProposal: Get<_> for const MAX_PROPOSAL: _.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, ok. I think that in the future it may be worth a large-scale refactor to use actual consts and const generics instead of faking it with type parameters, but that may have to wait for Frame 3.0.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We would already have switched to associated consts if it would be beneficial. The main advantage of using the trait is that we are much more flexible in tests. Overwriting constants would be a mess. Now we can just use thread local variables to overwrite the values.

And than there are also test runtimes where the trait enables us to read variables from the storage and thus, make it really flexible.

We would loose all this flexibility when using const generics.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, tests are also an issue with regard to const. Either of you know what kind of shenanigans we'd need to override consts? if possible at all?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We would need to make tests more generic, add new traits that provide the consts we want to override and implement X times, everytime with the const value we want. You see where this is going. This would not be easy and would just require tons of boilerplate without any advantage.

frame/support/src/storage/mod.rs Outdated Show resolved Hide resolved
frame/support/src/storage/mod.rs Outdated Show resolved Hide resolved
/// Storage value that is *maybe* capable of [`StorageAppend`].
pub trait TryAppendValue<T: Value, S: Get<u32>> {
fn try_append<LikeT: EncodeLike<T>>(item: LikeT) -> Result<(), ()>;
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why not creating TryStorageappend trait, and create the function fn try_append directly in StorageMap, StorageValue and StorageDoubleMap traits, with a where clause, similarly to fn append.

Also if you want those function to be accessible on storages without having to import trait in scope, then it should also be written in "frame/support/src/storage/types/value.rs"

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good, so far I tried to NOT add anything extra to the bast traits StorageValue and generator::StorageValue, but yeah this will enable us to not need to import the extra trait everywhere.

@gui1117
Copy link
Contributor

gui1117 commented Apr 13, 2021

having fn try_append inside the trait StorageMap/StorageValue/StorageDoubeMap, similarly to fn append can be good but is not necessary to me (in the past I liked to have everything in those traits so that people don't need to import to much trait in scope. but with frameV2 we don't need to import any trait to access method on storage, thus I'm fine anyway).

But I would like that we implement try_append on the structs StorageValue, StorageMap, and StorageDoubleMap (in frame/support/src/storage/types/) so that people can use these method without importing any trait.

(Apart from that we can improve to not require the value to be Eq, PartialEq, and Default, but this can be done later when needed.)

But otherwise it looks good to me

kianenigma and others added 2 commits April 13, 2021 12:48
* Example with balances

* Fix tests

* Make it indexable

* fix

* Fix tests

* fix test

* Fix collective as well

* Fix test
Co-authored-by: Peter Goodspeed-Niklaus <coriolinus@users.noreply.github.com>
@kianenigma
Copy link
Contributor Author

kianenigma commented Apr 14, 2021

having fn try_append inside the trait StorageMap/StorageValue/StorageDoubeMap, similarly to fn append can be good but is not necessary to me (in the past I liked to have everything in those traits so that people don't need to import to much trait in scope. but with frameV2 we don't need to import any trait to access method on storage, thus I'm fine anyway).

For now I kept them in separate traits that get a blanket implementation. If and when try_append becomes more useful, and we are sure that it should be a fundamental part of storage, we can mix the traits.

But I would like that we implement try_append on the structs StorageValue, StorageMap, and StorageDoubleMap (in frame/support/src/storage/types/) so that people can use these method without importing any trait.

Done.

(Apart from that we can improve to not require the value to be Eq, PartialEq, and Default, but this can be done later when needed.)

Also done.


  • I also merged the upstream PR, so now this PR contains examples for balances and proposals.
  • nonetheless, this is all fine since the encoding of Vec<T> and BoundedVec<T, _> is the same.
  • I repotted everything related to bounded_vec to a new file, but nothing changes since previous reviews.

Copy link
Contributor

@gui1117 gui1117 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks good to me

frame/support/src/storage/bounded_vec.rs Outdated Show resolved Hide resolved
Co-authored-by: Guillaume Thiolliere <gui.thiolliere@gmail.com>
Copy link
Contributor

@apopiak apopiak left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

some nits

frame/collective/src/lib.rs Show resolved Hide resolved
frame/support/src/storage/bounded_vec.rs Outdated Show resolved Hide resolved
frame/support/src/storage/bounded_vec.rs Show resolved Hide resolved
Copy link
Member

@shawntabrizi shawntabrizi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks like a great start :)

Need an issue to migrate existing vecs into the boundedvec

@kianenigma
Copy link
Contributor Author

bot merge

@ghost
Copy link

ghost commented Apr 16, 2021

Waiting for commit status.

@ghost ghost merged commit 8c4e296 into master Apr 16, 2021
@ghost ghost deleted the kiz-bounded-vec branch April 16, 2021 06:06
arjanz added a commit to polkascan/py-scale-codec that referenced this pull request May 3, 2021
@jakoblell jakoblell added D1-audited 👍 PR contains changes to fund-managing logic that has been properly reviewed and externally audited and removed D5-nicetohaveaudit ⚠️ PR contains trivial changes to logic that should be properly reviewed. labels May 31, 2021
This pull request was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
A0-please_review Pull request needs code review. B0-silent Changes should not be mentioned in any release notes C1-low PR touches the given topic and has a low impact on builders. D1-audited 👍 PR contains changes to fund-managing logic that has been properly reviewed and externally audited
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants