-
Notifications
You must be signed in to change notification settings - Fork 667
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PalletId
should be hardcoded into Pallet, not exposed as Config
#324
Comments
The same as we had with the storage prefix? Why? We switched to using the name of the pallet in the runtime to prevent clashing of the identifiers. How should we prevent here that someone uses the same identifier? |
(Pallet ID, instance ID) pairs are intended to be unique within a runtime. As long as this holds, then there's no reason to clog up runtimes with another trait config item. If there's some reason this is not achievable, then the decision could be revisited. |
in pallet macro we don't bound the so there is no id associated to the instance. But we can use PalletInfo::index to get a unique index for the pallet. Though I agree would be better to have |
Either way, I would prefer that a unique ID per pallet instance be provided by Frame rather than be passed in through a config trait type. |
paritytech/substrate#8630 give easy accessor to pallet index and pallet name. Such index and name are unique for the pallet and can be used through PalletInfoAccess trait which is implemented for the Pallet struct.
The name and the index are part of the metadata. Thus I think this issue is solved |
@thiolliere also needs to update existing pallets which do expose module id to close this fully |
Hey, is anyone still working on this? Due to the inactivity this issue has been automatically marked as stale. It will be closed if no further activity occurs. Thank you for your contributions. |
Also needs proper testing to ensure that we dont break existing deposits in pallet accounts. |
I don’t know how it is possible to implement this without potentially breaking existing chains? And we should not require chains to perform migration for sake of nothing |
PalletId
is intended to be a unique global identifier for a Pallet, and should not be configurable in the Pallet Config.Wherever
PalletId
is exposed in the runtime config, move it into the Pallet as aconst
and make sure thatconst
is exposed via the metadata.Make sure there are no breaking changes for Polkadot / Kusama
cc @gavofyork
The text was updated successfully, but these errors were encountered: