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

Make pallet_referenda::TracksInfo::tracks return type more flexible #3420

Open
olanod opened this issue Feb 21, 2024 · 2 comments
Open

Make pallet_referenda::TracksInfo::tracks return type more flexible #3420

olanod opened this issue Feb 21, 2024 · 2 comments

Comments

@olanod
Copy link
Contributor

olanod commented Feb 21, 2024

At the moment the return type of pallet_referenda::TracksInfo::tracks is a slice of tracks with a static lifetime, the trait is not very flexible as it only allows simple implementations where the tracks have to be hard-coded, relaxing this signature can open up new use cases like updating existing tracks without runtime upgrades(to avoid this) or a "dao pallet" that can create tracks on the fly and leverage the existing infrastructure provided by referenda.

In PR #2072 I propose returning an Iterator of Cow<'static, Track<_, _, _>>, it keeps compatibility with existing implementations that might want to keep defining tracks statically for performance reasons, it allows returning owned tracks that might come from the chain storage or a combination of both. An alternative of returning a Vec<Track>> is not ideal as it would still restrict us to less performant and more memory hungry implementations.

@gavofyork
Copy link
Member

Sounds sensible. As long as it doesn't impact performance for the base case not add substantial additional logic then I'm in favour.

@Polkadot-Forum
Copy link

This issue has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/opengov-for-everyone-1-ksm-1-dao/7781/1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants