-
Notifications
You must be signed in to change notification settings - Fork 2
Group module genesis in/export #60
base: master
Are you sure you want to change the base?
Conversation
7eaf072
to
a98de77
Compare
a98de77
to
cd6f2f5
Compare
cd6f2f5
to
a771879
Compare
76a6980
to
4c156db
Compare
a771879
to
5dc4fd1
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.
In general, it probably makes sense to do this in coordination with cosmos/cosmos-sdk#5917 as we will likely standardize on an approach for genesis in an ADR. I think the approach of using tables to do the exporting is sensible.
voteByProposalBaseIndex orm.UInt64Index | ||
voteByVoterIndex orm.Index | ||
VoteByProposalBaseIndex orm.UInt64Index | ||
VoteByVoterIndex orm.Index |
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.
What's the reason for making all of these public?
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 needed them available for tests. Indexes are read only and this should not create any harm.
5dc4fd1
to
087ed43
Compare
087ed43
to
422f756
Compare
message GenesisState { | ||
option (gogoproto.equal) = true; | ||
option (gogoproto.goproto_stringer) = false; | ||
Params Params = 1 [(gogoproto.nullable)=false]; | ||
Params Params = 1 [(gogoproto.nullable) = false]; | ||
uint64 GroupSeq = 2; | ||
bytes Groups = 3 [(gogoproto.casttype) = "encoding/json.RawMessage"]; | ||
bytes GroupMembers = 4 [(gogoproto.casttype) = "encoding/json.RawMessage"]; | ||
uint64 GroupAccountSeq = 5; | ||
bytes GroupAccounts = 6 [(gogoproto.casttype) = "encoding/json.RawMessage"]; | ||
uint64 ProposalSeq = 7; | ||
bytes Proposals = 8 [(gogoproto.casttype) = "encoding/json.RawMessage"]; | ||
bytes Votes = 9 [(gogoproto.casttype) = "encoding/json.RawMessage"]; | ||
} |
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 what if we were to take an approach like this where AnyGroupAccountMetadata and AnyProposal come from #63 and leverage google.protobuf.Any
?
message GenesisState {
Params params = 1;
uint64 group_seq = 2;
repeated GroupMetadata groups = 3;
repeated GroupMember group_members = 4;
uint64 group_account_seq = 5;
AnyGroupAccountMetadata group_acconts = 6;
uint64 proposal_seq = 7;
repeated AnyProposal proposals = 8;
repeated Vote votes = 9;
}
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.
With using concrete types rather than json bytes we can not simply let the orm layer do the en-/decoding. I am wondering now what are the benefits of concrete types here? The genesis is only used for data import/ export.
We won't get additional type safety as this is already covered within orm. But I guess it is easier to read and understand what would be inside the json bytes. Although with Any
types this is not obvious again.
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 wonder if you have any more thoughts after seeing the Any proposal? Also are you familiar with how the current SDK genesis encodes interfaces?
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 may be a bit biased by the implementation already. The orm store requires concrete types and won't work with interfaces. For the genesis in/export I was just focused on "it should work automated by the orm framework layer". I can spike a protobuf version
After #59
See #46
Example json export