-
Notifications
You must be signed in to change notification settings - Fork 733
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
Extend Consideration
trait
#1813
Conversation
I don't see any dependency on This approach seems fine to me. |
The dependency is introduced when using See #1569 (Edited, it wasn't linking to the right place) |
The dev only needs to specify the All implementations of |
bot fmt |
@NachoPal https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/3922343 was started for your command Comment |
@NachoPal Command |
/// Create a ticket for a `new` balance attributable to `who`. This ticket *must* ultimately | ||
/// be consumed through `update` or `drop` once the footprint changes or is removed. | ||
/// This is useful when a new ticket needs to be created with a precise balance, instead of | ||
/// deriving it from a footprint |
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.
The doc comment still mentions a footprint
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.
High level, one of the main goals of Consideration
is to abstract away the need for the existence of any "Balance/Currency" sub-system in a runtime, the fact that we need to add a Balance
generic to the trait now seems like the wrong compromise to me.
I recall this was solving an important issue with migrations though, so I would not block it. Possibly it can be a temporary hack, in which case you can document the method as "it is temporary".
What alternatives we have?
Which migrations would benefit from this? |
@juangirini Those were the During the migration, the new Let's say that during the migration, the new
@kianenigma The only alternative I see is to waive the deposit and not generate any ticket. |
After discussing it I think it would be less invasive to create a type solely for migrating from Currency. |
@@ -208,11 +208,17 @@ where | |||
/// treated as one*. Don't type to duplicate it, and remember to drop it when you're done with | |||
/// it. | |||
#[must_use] | |||
pub trait Consideration<AccountId>: Member + FullCodec + TypeInfo + MaxEncodedLen { | |||
pub trait Consideration<AccountId, Balance>: Member + FullCodec + TypeInfo + MaxEncodedLen { |
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.
Gah! No!
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.
Considerations need not have anything to do with balances.
Closing it. I'll give it a try to this alternative: #1813 |
* Backport xcm bridging extensions to the bridge repo * Fixes * Fixes
Draft exploring the idea of extending
Consideration
trait withnew_from_exact(who: &AccountId, new: Balance)
It would be useful for migrations from
Deposits
toConsideration
tickets where a fixedFootprint
might not always return the expected depositedBalance
.Is it possible to do it in a different way? right now it creates a dependency on
Currency
, which I think is actually supposed to be removed in favor ofConsideration
.