You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The new migrate versioning coming in 2.1 uses integers to go from old to new version in a way that allows convenetly supporting a variety of old versions. This way not all instances need to be on the latest version to be able tto upgrade. Migrate code then looks more or less like this:
#[entry_point]#[state_version(6)]pubfnmigrate(deps:DepsMut,env:Env,msg:MigrateMsg) -> StdResult<Response>{// if statements mimic a C/C++/Java swich statement with fallthrough semanticsif(old_version <= 3){panic("Unsupported version, migrate to intermediate version first");}if(old_version <= 4){// add a field to config and set a default value}if(old_version <= 5){// copy some data from old format to new}if(old_version <= 6){// Send funds to community pool}if(old_version > 6){panic("Downgrades are not supported");}}
and if old_version equals the #[state_version(6)], the migrate entry point is not called.
Now @AmitPr brought up is that in practice, not all actions in the migrate entry point are state layout changes. Sometimes you just send funds around. Maybe you could elaborate on non-state layout changing migrations?
But the point is: we can simply generalize the naming to e.g. "migrate version".
Re:non-state changing migrations: For example, some of our contracts have had cases where rounding issues or other logic-related issues caused funds to sit in the contract when they should have been sent elsewhere.
To fix this, we would patch the logic in the contract, and create a migration to incorporate this change, and to also transfer any funds that were locked in the contract due to this type of bug. There were no state changes -- only WASM binary changes, but we still made use of the migrate function to clean up things like bank balances (or, in some cases, calling into other external contracts, etc.).
(Follow-up to #2116)
The new migrate versioning coming in 2.1 uses integers to go from old to new version in a way that allows convenetly supporting a variety of old versions. This way not all instances need to be on the latest version to be able tto upgrade. Migrate code then looks more or less like this:
and if old_version equals the
#[state_version(6)]
, the migrate entry point is not called.Now @AmitPr brought up is that in practice, not all actions in the migrate entry point are state layout changes. Sometimes you just send funds around. Maybe you could elaborate on non-state layout changing migrations?
But the point is: we can simply generalize the naming to e.g. "migrate version".
cc @kulikthebird
The text was updated successfully, but these errors were encountered: