Skip to content
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

Open
shawntabrizi opened this issue Apr 9, 2021 · 9 comments
Open
Labels
C1-mentor A task where a mentor is available. Please indicate in the issue who the mentor could be. D2-substantial Can be fixed by an experienced coder with a working knowledge of the codebase. I10-unconfirmed Issue might be valid, but it's not yet known.

Comments

@shawntabrizi
Copy link
Contributor

shawntabrizi commented Apr 9, 2021

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 a const and make sure that const is exposed via the metadata.

Make sure there are no breaking changes for Polkadot / Kusama

cc @gavofyork

@bkchr
Copy link
Member

bkchr commented Apr 9, 2021

PalletId is intended to be a unique global identifier for a Pallet, and should not be configurable in the Pallet Config.

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?

@gavofyork
Copy link
Member

(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.

@thiolliere
Copy link
Contributor

thiolliere commented Apr 15, 2021

in pallet macro we don't bound the Instance trait since we don't use it to get the pallet prefix to use for storages.
(Instead we only bound 'static because we need Pallet<T, I> to be static in order to call PalletInfo::name::<Pallet<T, I>>())

so there is no id associated to the instance.

But we can use PalletInfo::index to get a unique index for the pallet.
<T as frame_system::Config::PalletInfo>::index::<Pallet<T, I>>().expect("pallet is part of the runtime")

Though I agree would be better to have fn index directly implemented on Pallet by the macro which would call that inside (or anything so we can quickly get access to the index).

@gavofyork
Copy link
Member

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.

@thiolliere
Copy link
Contributor

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.

Pallet::<T>::index();

The name and the index are part of the metadata.

Thus I think this issue is solved

@shawntabrizi
Copy link
Contributor Author

shawntabrizi commented Apr 25, 2021

@thiolliere also needs to update existing pallets which do expose module id to close this fully

@stale
Copy link

stale bot commented Jul 7, 2021

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.

@stale stale bot added the A5-stale label Jul 7, 2021
@bkchr bkchr removed the A5-stale label Aug 4, 2021
@juangirini juangirini transferred this issue from paritytech/substrate Aug 24, 2023
@the-right-joyce the-right-joyce added I10-unconfirmed Issue might be valid, but it's not yet known. C1-mentor A task where a mentor is available. Please indicate in the issue who the mentor could be. D0-easy Can be fixed primarily by duplicating and adapting code by an intermediate coder. and removed J2-unconfirmed labels Aug 25, 2023
claravanstaden pushed a commit to Snowfork/polkadot-sdk that referenced this issue Dec 8, 2023
helin6 pushed a commit to boolnetwork/polkadot-sdk that referenced this issue Feb 5, 2024
@ggwpez ggwpez added D2-substantial Can be fixed by an experienced coder with a working knowledge of the codebase. and removed D0-easy Can be fixed primarily by duplicating and adapting code by an intermediate coder. labels Feb 5, 2024
@ggwpez
Copy link
Member

ggwpez commented Feb 5, 2024

Also needs proper testing to ensure that we dont break existing deposits in pallet accounts.

@xlc
Copy link
Contributor

xlc commented Feb 7, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C1-mentor A task where a mentor is available. Please indicate in the issue who the mentor could be. D2-substantial Can be fixed by an experienced coder with a working knowledge of the codebase. I10-unconfirmed Issue might be valid, but it's not yet known.
Projects
Status: Backlog
Development

No branches or pull requests

7 participants