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.
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
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)]