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

Depreciate missing pallet::storage_version #13435

Closed
ggwpez opened this issue Feb 22, 2023 · 2 comments
Closed

Depreciate missing pallet::storage_version #13435

ggwpez opened this issue Feb 22, 2023 · 2 comments

Comments

@ggwpez
Copy link
Member

ggwpez commented Feb 22, 2023

Our migration tooling revolves around the idea of each pallet having a storage version. Now the fact that pallets are not required to declare such a version makes additional code necessary to deal with these cases (eg #13417).

I would therefore propose to depreciate missing pallet::storage_version attributes and print a warning (for now) akin to implicit call indices. The dev-mode could keep them obviously.

@bkchr
Copy link
Member

bkchr commented Feb 22, 2023

Our migration tooling revolves around the idea of each pallet having a storage version.

Every pallet also has a storage version. If you don't provide any storage version, the storage version is set to 0. This is actually a save and valid default value IMO. For most pallets that are enough for a long time, until you need to write some migration. I'm not convinced that we require a storage version before this point. We also don't really have any automatic tooling around the storage version as you as a developer are required to write manually all this storage version checking code. The attribute macro only exists for having a way to store the current version on genesis in the state, otherwise we don't need this.

@ggwpez
Copy link
Member Author

ggwpez commented Feb 22, 2023

Okay. Then the only thing a dev has to be aware of, is to start a pallet with STORAGE_VERSION(1) and not 0, if the 0 was already implicitly placed by FRAME. So could we forbid explicit 0 versioning, but it would probably bring more pain than utility.
Seems fine now 👍

We also don't really have any automatic tooling around the storage version as you as a developer are required to write manually all this storage version checking code.

Yes… maybe soon #13107

@ggwpez ggwpez closed this as completed Feb 22, 2023
@github-project-automation github-project-automation bot moved this from Backlog to Done in Runtime / FRAME Feb 22, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
Status: Done
Development

No branches or pull requests

2 participants