-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
x{stake,slash,gov,distrib} In-place Store Migrations #8504
Conversation
7c76245
to
f9decc0
Compare
Co-authored-by: Robert Zaremba <robert@zaremba.ch>
Co-authored-by: Robert Zaremba <robert@zaremba.ch>
…k into am-8345-migration
Co-authored-by: Robert Zaremba <robert@zaremba.ch>
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.
Few remarks:
- Let's avoid extending Keeper responsibility for handling migrations. In a comment I proposed 2 options.
- We put migrations in
legacy
package. This pattern forces to copy current code to into a legacy package, before it gets legacy - I would prefer to limit the amount of code we copy (there are functions we copied which are not used).
// Migrate1 implements MigrationKeeper.Migrate1 method. | ||
func (keeper Keeper) Migrate1(ctx sdk.Context) error { | ||
return v042.MigrateStore(ctx, keeper.storeKey) | ||
} |
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.
Instead of enlarging the Keeper
interface and responsibilities, let's create a Migrator
structure:
type Migrator struct {
keeper Keeper
}
// in RegisterServies
m := Migrator(keeper)
cfg.RegisterMigration(types.ModuleName, 1, m.Migrate1)
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.
Other idea is just to make this functions directly:
cfg.RegisterMigration(types.ModuleName, 1,
func (ctx) {return v42.MigrateStore(ctx, keeper.storeKey)
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.
func (ctx) {return v42.MigrateStore(ctx, keeper.storeKey)
This would be ideal, but we can't access private keeper.storeKey
there.
OK for the Migrator way.
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.
binary.BigEndian.PutUint64(periodBz, period) | ||
prefix := GetValidatorSlashEventKeyPrefix(v, height) | ||
return append(prefix, periodBz...) | ||
} |
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.
Do we need to copy all this functions? For example, it seams that the function above is not used in migrations.
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.
Yeah, for legacy stuff, I'm not trying to optimize. Just copy-pasting the whole file seems easier than going through in details what's needed and what's not.
lmk what you think.
@@ -0,0 +1,70 @@ | |||
package v042 |
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.
why do we create legacy/v042
? This version is not even released .
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.
Yeah okay, we can create that later, I'll use types
for now.
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 removed the legacy/*/keys.go
in f3ca3e5 . However I kept the v042 package, because the migration script from 0.41
->0.42
lives in legacy/*/v042
.
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.
So that was my point - why putting the migration code in legacy/*/v042
? v0.42 is not legacy. It's "current"
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.
Ah I see. Well imo it shoud live in a folder called x/module/{something}/v042
. We can rename something
from "legacy" to "migrations" in a future PR if you want.
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.
yeah, migrations
sounds better
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.
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.
Good. Thanks for updating the package structure.
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.
Can you explain your logic for starting ConsensusVersion
at 1
@AmauryM? Maybe you addressed this in #8485 already but it seems like it would be simplest if we just used the default value of 0
. What scenarios are you trying to deal with using 1
? Are you thinking that 0
would represent the absence of a module?
@aaronc Main reason is to explicit set values for all modules in the MigrationMap to avoid potential mistakes: #8485 (comment) Edit: "Are you thinking that 0 would represent the absence of a module?" Thinking about it, that could be useful too? To differentiate new modules from existing |
Okay, so basically if the existing version is 0, that actually means the module was just added in this upgrade and therefore shouldn't have any old state migrated. Is that the idea? |
Yes. |
x/bank/keeper/migrations.go
Outdated
func (keeper BaseKeeper) Migrate1(ctx sdk.Context) error { | ||
return v042.MigrateStore(ctx, keeper.storeKey) | ||
// Migrate1 migrates from version 1 to 2. | ||
func (m Migrator) Migrate1(ctx sdk.Context) error { |
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.
How about naming this as Migrate1to2
?
@@ -0,0 +1,70 @@ | |||
package v042 |
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.
yeah, migrations
sounds better
* Add 1st version of migrate * Put migration logic into Configurator * add test to bank store migration * add test for configurator * Error if no migration found * Remove RunMigrations from Configurator interface * Update spec * Rename folders * copy-paste from keys.go * Fix nil map * rename function * Update simapp/app.go Co-authored-by: Robert Zaremba <robert@zaremba.ch> * Update simapp/app_test.go Co-authored-by: Robert Zaremba <robert@zaremba.ch> * Adderss reviews * Fix tests * Update testutil/context.go Co-authored-by: Robert Zaremba <robert@zaremba.ch> * Update docs for ConsensusVersion * Rename to forVersion * Fix tests * Check error early * Return 1 for intiial version * Use MigrationKeeper * Fix test * Revert adding marshaler to Configurator * Godoc updates * Update docs * Add distrib legacy folder * Add tests for distrib migration * Add gov migrations * Copy paste whole keys file * Add gov migrations * Add staking * Fix staking tests * Update spec and module.go * Update to latest changes * Update migration scripts * capability to 1 * Fix tests * Add package godoc * Remove whitespace * Remove global * Use Migrator * Remove 042 keys files * Fix build * Unlambda * Rename to Migrate1to2 Co-authored-by: Robert Zaremba <robert@zaremba.ch>
Description
Add in-place store key migrations in
x{stake,slash,gov,distrib}
module'slegacy
folder:keys.go
(from the 41), put them inlegacy/041/keys.go
ref: #8345
depends on: #8485
Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.
docs/
) or specification (x/<module>/spec/
)godoc
comments.Unreleased
section inCHANGELOG.md
Files changed
in the Github PR explorerCodecov Report
in the comment section below once CI passes