remove storage getters in FRAME#13365
remove storage getters in FRAME#13365muraca wants to merge 1 commit intoparitytech:masterfrom muraca:issue/13259
Conversation
|
I'm sure I missed something, I'll let the tests run to see if there's any errors in pallets. |
|
Do we really want to do this like this? This is a big breaking change and will add significantly amount of work to downstream projects for no benefits. It makes some sense to deprecate the getter syntax, but please don't remove the getters from pallets immediately. |
Indeed, as per the original issue:
|
|
No problem then, I'll revert those changes! |
|
Polkadot and Cumulus tests fail because of a missing |
shawntabrizi
left a comment
There was a problem hiding this comment.
looks like the right direction to me
I think this is how @muraca already approached this problem, but better to just manually implement all the getters on existing pallets, and no need to really mark anything as deprecated. Basically, this is just some legacy debt that probably will stick around, but has little impact. |
|
Please don't close the linked issue with this PR, as we still need to revisit this and make sure we remove the code after some time has passed. |
|
This pull request has been mentioned on Polkadot Forum. There might be relevant details there: https://forum.polkadot.network/t/less-magic-in-frame-good-or-bad/2287/1 |
|
@muraca rebase please? |
|
this needs to be rebased on current master, there have been breaking changes to the check-crate-publishing job. |
|
@liamaharon / @gupnik if @muraca does not show up, can either of you push this to the finish line? Seems like it is mostly done. We can mark PR as "made with ❤️ by PBA students" :)) |
I just spoke with @gupnik, I can take it on if we don't hear from @muraca before next week |
There was a problem hiding this comment.
Hi for the pallet-sudo, the definition for the Key is under super scope limitation.
Maybe you forget to remove the getter for the key, but all in all, if you plan to remove getter for the storage Key, please at least make the Key to be pub. Because in many projects including our, we use the sudo key to check something in other pallets. So that for this pr modification, we need to let the sudo key can be accessed from outside, I advise you to choose the following two way:
- let the storage
Keyto be public; - write a function
key()to return this storage, impl same logic asgetterfunction.
There was a problem hiding this comment.
The key function is not going to be removed as of now, but the auto-generated getter is being deprecated.
I can speculate about what might happen in the future, I think that somebody will "manually" implement such getters, and remove the pallet::getter from the pallets, but from what I understood it's going to take a while.
cc @kianenigma
There was a problem hiding this comment.
Yes, I mean when remove the getter for Key, please do not forget to let it be pub or implement the getter manually, otherwise we need to create another pr to add it.
Thanks
There was a problem hiding this comment.
@muraca I see that this pallet-sudo already remove this getter, so please do not forget to add this getter by manual or let the Key be pub
There was a problem hiding this comment.
I have not removed the #[pallet::getter(fn key)] line. See here.
There was a problem hiding this comment.
so can you add this function in this pallet-sudo? otherwise it will breaking many thing in our projects ? @muraca
pub fn key() -> Option<T::AccountId>{
Key::<T>::get()
}I think it's very necessary! otherwise there is no way to get the sudo key from this pallet!
|
why is this removing getters instead of deprecate them? |
|
@xlc as per request, I added a deprecation message and removed every usage of the auto-generated functions |
|
But the getter is still removed? There shouldn't be any companions PR required for this PR. |
Ahh yeah good point, we should first deprecate the usage before removing the actual calls. |
@xlc I'm not sure I understood what you're asking. I'm not actually removing any of the getter functions, it just shows a warning message if you try to use one. I was told I should not leave any warning behind, so I removed all the calls to said auto-generated functions in the FRAME pallets, and I did the same for the Cumulus repository. |
|
Ahh yeah, thank you @muraca! |
xlc
left a comment
There was a problem hiding this comment.
ok I think you do the correct thing for most of the pallets but may have missed a few others.
My suggestion: always avoid hugh PR if possible. This is no reason that you need to update every pallet in a single PR. This makes review impossible (Github struggling to render diff and very time comsuming for reviews).
|
|
||
| /// The total units issued in the system. | ||
| #[pallet::storage] | ||
| #[pallet::getter(fn total_issuance)] |
There was a problem hiding this comment.
A method with the same name and return value is implemented in Currency and fungible::Inspect
Signed-off-by: muraca <mmuraca247@gmail.com>
|
The CI pipeline was cancelled due to failure one of the required jobs. |
|
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. |
|
@muraca unfortunately this got behind master massively, would you take this over? |
|
Hey @juangirini as far as I remember it was decided not to proceed with this deprecation at the moment. |
|
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. |
resolves paritytech/polkadot-sdk#223
I added the deprecation message, removed every usage of
#[pallet::getter]and refactored everything accordingly.Since a few getters for non-public maps were used in runtime or other situations, I manually wrote those functions and removed the getter.
I generally used the
pallet_name::StorageItem::<T>::get()syntax, I don't like theuse pallet_name::StorageItem;because it's less explicit.I removed the getters from the examples, because since we don't want users to use them anymore, I think it's a better UX if we just don't mention them.
Companions:
Cumulus paritytech/substrate#2216
Polkadot TBD