This came up in a discussion with @gpestana recently. There are a number of Get<_> associated types in a runtime that should not really change after being once set. If they are to be changed, we probably need a migration. For example, all of the type MaxSomething: Get<u32> might imply a migration if we reduce them.

The idea is to mark these with a special flag that says they should not change. I am not sure if non_volatile is a good word here. Then, in construct_runtime!, if we optionally provide either an encoded metadata path, or a websocket endpoint from which the existing metadata can be fetched, we can compare the values, and if anything has changed, we emit a warning.

sub-xt can be useful to do all of these.

0

Having volatile constants is a weird design to begin with. I think a constant should be constant by definition.
Maybe:

#[pallet::constant] // non-volatile
#[pallet::variable] // volatile
2

totally agree, and taking it a step further, I think pallet::constant was bad to begin with because the name doesn't have much to do with the semantic, which is "put it in metadata".

#[pallet::metadat(constant)]
#[pallet::metadat(variable)]
2

related: https://github.com/paritytech/substrate/issues/11619

0
© 2022 pullanswer.com - All rights reserved.