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

R4R [Staging PR 1/3]: module generalization #4033

Closed
wants to merge 35 commits into from

Conversation

rigelrozanski
Copy link
Contributor

@rigelrozanski rigelrozanski commented Apr 3, 2019

Most downstream PR
Upstream Staging #4128

closes #3006
REF affects #3976

  • Targeted PR against correct branch (see CONTRIBUTING.md)

  • Linked to github-issue with discussion and accepted design OR link to spec that describes this work.

  • Wrote tests

  • Updated relevant documentation (docs/)

  • Added a relevant changelog entry: sdkch add [section] [stanza] [message]

  • rereviewed Files changed in the github PR explorer


For Admin Use:

  • Added appropriate labels to PR (ex. wip, ready-for-review, docs)
  • Reviewers Assigned
  • Squashed all commits, uses message "Merge pull request #XYZ: [title]" (coding standards)

@codecov
Copy link

codecov bot commented Apr 4, 2019

Codecov Report

Merging #4033 into develop will decrease coverage by 0.78%.
The diff coverage is 32.91%.

@@             Coverage Diff             @@
##           develop    #4033      +/-   ##
===========================================
- Coverage    60.16%   59.38%   -0.79%     
===========================================
  Files          212      220       +8     
  Lines        15187    15284      +97     
===========================================
- Hits          9137     9076      -61     
- Misses        5421     5581     +160     
+ Partials       629      627       -2

cmd/gaia/app/hooks.go Outdated Show resolved Hide resolved
types/module.go Outdated Show resolved Hide resolved
types/module.go Outdated Show resolved Hide resolved
types/module.go Outdated
// routes
Route()
NewHandler()
QuerierRoute()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As a side note, can we make queriers more like the handler? Cause right now there is that whole path[0] thing...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know what you mean... handlers and queriers follow a very similar pattern... open up a new issue? probably should be tackled outside of this PR

@rigelrozanski
Copy link
Contributor Author

thanks for the comments @jack - yeah there were a few missing returns in the module type as I hadn't attempted to roll with it yet

@rigelrozanski
Copy link
Contributor Author

rigelrozanski commented Apr 10, 2019

There is a fun breaking test as a part of test_sim_gaia_import_export where the store's nolonger match at this commit (45d82f9) which doesn't really do a whole lot in terms of the store changing.

the command to run is
go test ./cmd/gaia/app -run TestGaiaImportExport -SimulationEnabled=true -SimulationNumBlocks=2 -SimulationVerbose=true -SimulationCommit=true -SimulationSeed=4 -v -timeout 24h

type queryRouter struct {
routes map[string]sdk.Querier
}

var _ sdk.QueryRouter = NewQueryRouter()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does the QueryRouter implementation also want to live in types too?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, for the reason mentioned in my previous comment

type router struct {
routes map[string]sdk.Handler
}

var _ sdk.Router = NewRouter()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does the sdk.Router implementation want to live in types too?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correct it's required to live there in order to not cause circular dependancies because the ModuleManager wants to use the the router interface

@@ -231,7 +231,7 @@ func TestCoinMultiSendGenerateOnly(t *testing.T) {
var stdTx auth.StdTx
require.Nil(t, cdc.UnmarshalJSON([]byte(body), &stdTx))
require.Equal(t, len(stdTx.Msgs), 1)
require.Equal(t, stdTx.GetMsgs()[0].Route(), "bank")
require.Equal(t, stdTx.GetMsgs()[0].Route(), bank.RouterKey)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doesn't the AppModule interface have a Name()? Should we be using that instead?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I can just kinda change everything to be using the module name, I've currently left things moreless how their structured which is define other constants to the name and then pass those these ways... I'm not sure that really makes sense - probably everything should just be switched to the module name aye?

cmd/gaia/app/app.go Show resolved Hide resolved
cmd/gaia/app/genesis.go Show resolved Hide resolved
@@ -202,6 +189,18 @@ func GaiaAppGenState(cdc *codec.Codec, genDoc tmtypes.GenesisDoc, appGenTxs []js
return genesisState, nil
}

// GaiaAppGenState but with JSON
func GaiaAppGenStateJSON(cdc *codec.Codec, genDoc tmtypes.GenesisDoc, appGenTxs []json.RawMessage) (
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
func GaiaAppGenStateJSON(cdc *codec.Codec, genDoc tmtypes.GenesisDoc, appGenTxs []json.RawMessage) (
func GaiaAppGenStateToJSON(cdc *codec.Codec, genDoc tmtypes.GenesisDoc, appGenTxs []json.RawMessage) (

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure this change makes sense because this function doesn't take genesisState as an input. (this is just a moved function)

types/module.go Show resolved Hide resolved
types/module.go Show resolved Hide resolved
types/router.go Show resolved Hide resolved
types/staking.go Outdated Show resolved Hide resolved
@alexanderbez
Copy link
Contributor

Started a (partial) review; I will complete later, but feel free to continue and make progress 👍


// NewModuleManager creates a new ModuleManager object
func NewModuleManager(modules ...AppModule) *ModuleManager {

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe the module manager wants to store the []string of the order in which the modules were passed in and save it as a default for some of the SetOrder* functions?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm good idea! - this will save on if statement's latter on

types/staking.go Outdated
@@ -160,3 +160,62 @@ type StakingHooks interface {
AfterDelegationModified(ctx Context, delAddr AccAddress, valAddr ValAddress)
BeforeValidatorSlashed(ctx Context, valAddr ValAddress, fraction Dec)
}

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are these hooks generally useful for other staking implementations? Or is this something that could/should live in x/staking?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm yeah good point this belongs in x/staking

)

// name of this module
const ModuleName = "auth"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not const Name = "auth" -> auth.Name?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're going to need to elabourate

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think @jackzampolin is taking this from the auth module user perspective as in he'd like to reference the module's name simply as Name instead of ModuleName. @jackzampolin correct me if I am wrong

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh yeah that makes sense

func (AppModule) RegisterInvariants(_ sdk.InvariantRouter) {}

// module message route name
func (AppModule) Route() string { return "" }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't this supposed to be (or something similar):

func (AppModule) Route() string { return TransactionRoute }

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are no routes, but this function still need to exist to fulfill the AppModule interface

func (AppModule) Route() string { return "" }

// module handler
func (AppModule) NewHandler() sdk.Handler { return nil }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is just not implemented right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

see above comment

}

// NewAppModule creates a new AppModule object
func NewAppModule(keeper Keeper, accountKeeper auth.AccountKeeper) AppModule {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we pass keys in instead and create the keepers in the modules?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Due to the interdependence of the keepers on each other that would make things much uglier at the app.go level. I think the high level wiring of the keepers together should stay as is

Copy link
Contributor

@alessio alessio left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Except for a small cosmetic bit that I assume will be fixed before merging this in, so far so good!

@rigelrozanski rigelrozanski changed the title INTERIM R4R: module genesis generalization R4R [Staging PR 1/3]: module genesis generalization Apr 18, 2019
@rigelrozanski rigelrozanski changed the title R4R [Staging PR 1/3]: module genesis generalization R4R [Staging PR 1/3]: module generalization Apr 19, 2019
Copy link
Collaborator

@fedekunze fedekunze left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Amazing refactor. LGTM

types/module.go Outdated Show resolved Hide resolved
@okwme okwme mentioned this pull request Apr 25, 2019
4 tasks
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

Successfully merging this pull request may close these issues.

7 participants