-
Notifications
You must be signed in to change notification settings - Fork 15
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
refactor: split out composite electoral system trait #5334
refactor: split out composite electoral system trait #5334
Conversation
82e531d
to
e628e89
Compare
81ebe55
to
ce2ca62
Compare
c3bd435
to
6d74b8a
Compare
state-chain/runtime/src/migrations/solana_egress_success_witness.rs
Outdated
Show resolved
Hide resolved
58eeb31
to
d1834bd
Compare
b4607d3
to
5ac5bdc
Compare
remove comment
5ac5bdc
to
75ed384
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not really convinced of the benefit of mocking the storage access trait... still feel like we could just use the actual pallet.
pub mod tags { | ||
pub struct A; | ||
pub struct B; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can probably define this within the generate
macro? (Doesn't have to be now)
And then maybe we can give these sensible names instead of A, B, C etc..
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sensible names is a little difficult, because every chain could be different, so if we named them "block height", "ingress" etc. depending on the chain, it could be different. Though, it's certainly on the radar as something that would be nice to improve if possible
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess what I mean is that we would use this macro at the runtime-level (ie. solana_elections.rs). We don't really need to define a generic that is only used once. But yeah - can wait for later ofc.
// These are synchronised with respect to an election, so for simplicity in the tests | ||
// we just assign them to an election. | ||
MockStorageAccess::set_electoral_settings::<ES>(setup.electoral_settings.clone()); | ||
MockStorageAccess::set_unsynchronised_state::<ES>(setup.unsynchronised_state.clone()); | ||
MockStorageAccess::set_unsynchronised_settings::<ES>(setup.unsynchronised_settings.clone()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't really understand the comment here. How are these 'assigned to an election'?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Made comment more explicit.
Pull Request
Closes: PRO-1675
Checklist
Please conduct a thorough self-review before opening the PR.
Summary
Rather than have a composite "electoral system" impl Electoral system, we now have a new
ElectoralSystemRunner
trait for the composite, which is then used by the elections pallet directly. This removes some prior hacks that were required to get the traits to work for both a single and composite electoral system.It also makes it easier to write migration utilities in the future, since storage will always be enum wrapped, as a composite, and we don't need to consider the individual electoral system case.
As a consequence there were other simplifications that fell out: