chore: remove old storage version and set new default #932
Conversation
Signed-off-by: Gregory Hill <gregorydhill@outlook.com>
| #[pallet::pallet] | ||
| #[pallet::generate_store(trait Store)] | ||
| #[pallet::storage_version(STORAGE_VERSION)] |
There was a problem hiding this comment.
What does this do, exactly? Does it set it to 0 when building genesis, or does it set the default to 1? What I'm saying is, kintsugi and interlay might actually get set to 0..
Also, the whole situation with palletVersion/storageVersion is a bit of a mess. I thought we'd use palletVersion, since that storage item already exists on polkadotjs. But then I found this pr, which changed the old palletVersion to storageVersion. It turns out that the palletVersion is no longer used and that the item shown by polkadotjs is actualy the storageVersion: polkadot-js/api#546.
There was a problem hiding this comment.
When performing an upgrade, we need to obtain the values for current_storage_version and on_chain_storage_version.
During the genesis build, we set the value for on_chain_storage_version, and in the macro, we set the value for current_storage_version.
For the runtime upgrade:
- Retrieve both values and compare them.
- In the code before the runtime upgrade Increment
current_storage_versionby one ie is theSTORAGE_VERSIONconstant value. - If the migration is successful, increment
on_chain_storage_versionby one as well. - Both the
on_chain_storage_versionandcurrent_storage_versionshould be the same if the runtime upgrade is successful. - But since we already have performed multiple runtime upgrades we need to make sure that
on_chain_storage_versionmatches thecurrent_storage_version. PR 1106 fixes it.
References:
- Stack Exchange: On-chain storage version on new chain seems to be incorrect
- Parity Documentation: GetStorageVersion trait - current_storage_version
Prevents the capacity migration from re-running and removes the completed v1 to v6 migration.