-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Optional storage hashers in pallet dev mode #13263
Comments
It's a good idea to simplify things, although I'm not completely sold on the fact that having an expensive hasher as default is the best idea. For dev mode - maybe. Yes, it is safe. But it also makes users unaware of the price they have to pay and the choices they can make when building pallets. Maybe we could have some aliases for hashers though, like Safe / Cheap or whatever to make it easier for people to understand and choose between the two? :) |
That is basically the point of the dev-mode; to hide complexity from new-comers. Otherwise it is just too complicated to understand. We also allow unbounded storage in there, which you dont want in production as much. Normally in Rust a map is written as as |
Sounds good, let's do this for dev-mode. However I'm still not sold on hiding this kind of complexity in production, as we work hard to NOT have magic, like for example pallet getters, we should not be easy on the users when they actually have to choose a hashing algorithm suitable for their purpose. |
This hide complexity from new-comers and make it harder later for them to build a production pallet. I don't really know if this is the right trade-off. |
Is it possible to introduce another mode as a "playground" where most things are set to reasonable defaults? I think that it would have definitely helped a lot of folks during the academy. |
The issue explicitly says this is only for dev-mode.
I get your point, but I am not convinced yet. We want more developers to be capable of onboarding into FRAME and trying new things. dev-mode is meant to enable that. Also, we already hide weight in dev-mode. So your comment is essentially the fact that you don't like dev-mode, not the hasher thing per se. Is it possible to introduce another mode as a "playground" where most things are set to reasonable defaults? I think that it would have definitely helped a lot of folks during the academy. I think dev-mode is basically that. It defaults them to something that is enough for you to have a dev/local testnet. @sam0x17 what is the default weight used in dev-mode? |
It is zero. Happy to change this if we think there is a more reasonable number for dev mode. Zero was on the original spec for dev mode that I inherited. |
I was mostly referring to this part of the issue description which mentions prod setup. |
So, is this a confirmed issue then or still pending discussion? I've taken a look at what "dev mode" is and I guess I'm convinced that it's fine to hide the hashers. That question will pop up once a pallet get switched over to production mode, which is when we could produce a comprehensive error present a user with a choice. Adoption is important and if this helps that - definitely worth doing it. |
replicating from my chat with @kianenigma, north star would be something like this: #[pallet::storage]
type Foo<T:Config> = StorageValue<T::AccountId>;
#[pallet::storage]
type Bar<T> = StorageMap<T::Key, T::AccountId>
#[pallet::storage]
type Bar<T> = StorageDoubleMap<T::Key1, T::Key2, T::AccountId> |
@sam0x17 image how you are going to write docs for this. The arguments changes based on some flag elsewhere. I don't think it is a good idea. |
Another option would be to just make |
|
Yeah I don't like dev-mode but I don't against as long as it doesn't cause new troubles. I would image dev mode is a superset of normal mode. i.e. all non-dev mode code should work with dev mode. Otherwise people can't take code from production pallet to dev mode without modify them. It shouldn't introduce too much new macro magic/syntax as well, which is something I believe we all agree that's not beginner friendly and wanting to reduce them. So instead of just magically omit a parameter, how about just make it i.e. #[pallet::storage]
type Bar<T> = StorageMap<_, _, T::Key, T::AccountId>
#[pallet::storage]
type Bar<T> = StorageDoubleMap<_, _, T::Key1, _, T::Key2, T::AccountId> You don't have to explain exactly what is |
This issue has been mentioned on Polkadot Forum. There might be relevant details there: https://forum.polkadot.network/t/less-magic-in-frame-good-or-bad/2287/1 |
This is a good north star. If this property is currently held, I am happy to support keeping it that way, ergo Another avenue would have been leveraging the fact that Rust generics actually support defaults, but then we would have to move the hashers to the end. This is a bit of an upheaval to the interface, but it would hit both targets at once:
That being said, using |
Closed. |
In dev-mode, all hashers could default to
Blake2_256_Concat
.We could also maintain the same in production, but omit a warning.
An idea that arose in the spirit of simplifying FRAME during the academy.
The text was updated successfully, but these errors were encountered: