-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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
feat(bank): Add secondary query for bank metadata #16852
Conversation
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 come this has changed?
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.
This I do not know, probably something to do with protoc or how we generate pulsar files, do you want me to revert this file 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.
Just running make proto-gen
should suffice.
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 have used the same command for proto gen 🤔 I'm wondering if we check docker image versions for protogen and if that might be the cause for this?
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.
utACK
@@ -225,6 +225,28 @@ func (k BaseKeeper) DenomMetadata(c context.Context, req *types.QueryDenomMetada | |||
}, nil | |||
} | |||
|
|||
// DenomMetadataByQueryString is identical to DenomMetadata query, but receives request via query string. | |||
func (k BaseKeeper) DenomMetadataByQueryString(c context.Context, req *types.QueryDenomMetadataByQueryStringRequest) (*types.QueryDenomMetadataByQueryStringResponse, 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.
Am I missine something but isn't this the same as DenomMetadata
?
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.
If the issue is just the fact that we MUST provide a denom in the URL path, then I would avoid creating a duplicate query handler -- we can at least extract out the handler code into a single method.
In addition, is there no annotation or something that we can add to the existing query to allow an empty query argument?
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.
we can at least extract out the handler code into a single method.
@alexanderbez We need to suffice the BaseKeeper Interface, thus need to have this method with this specific request field and response field. What I can do is extract the duplicated method between DenomMetadata
and DenomMetadataByQueryString` to reduce code duplication.
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.
Yes, the code within the query handlers are identical I believe, so that should be kept DRY 👍
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.
On the second look, the way it is right now seems as far as we could go for having non-duplicated code.
We use the same abstracted keeper method, namely k.GetDenomMetaData
whilst the remaining part is simply handling the request and response itself
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.
ACK
rpc DenomMetadataByQueryString(QueryDenomMetadataByQueryStringRequest) | ||
returns (QueryDenomMetadataByQueryStringResponse) { | ||
option (cosmos.query.v1.module_query_safe) = true; | ||
option (google.api.http).get = "/cosmos/bank/v1beta1/denoms_metadata_by_query_string"; |
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.
option (google.api.http).get = "/cosmos/bank/v1beta1/denoms_metadata_by_query_string"; | |
option (google.api.http).get = "/cosmos/bank/v1beta1/denoms_metadata_by_query"; |
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.
IMO, query string seems like the correct term to use, is there a reason for suggestion above?
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.
Yes, a few items:
- It makes an already verbose query even more verbose without adding context
- The fact that denom is a string is already available based on the proto schema
- Generally, you dont wan't to annotate a query's path (e.g. /users/by_name vs /users/by_name_string), the latter doesn't give you anything as it's superfluous IMO
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.
Oh I was referring to query string as a single term here though (https://en.wikipedia.org/wiki/Query_string)
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'm happy with it either way, but just wanted to make things clear :)
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.
Not a blocker for me, just my two cents :p
we can merge
If the naming is okay, can you run |
Gentle ping @mattverse |
@julienrbrt Done! |
(cherry picked from commit c295832) # Conflicts: # CHANGELOG.md # x/bank/keeper/grpc_query.go
Description
Current bank metadata query takes in denom field as query path, thus does not support querying any denom with "/". (Ex tokenfactory/~") cannot be queried through current query.
This PR adds secondary query for denom meta data, where here we take in query as query string, thus also supports query as above.
The reason this query is designed as a secondary query is because last time we have made similar change to the supply query, it was API breaking thus effected(broke) lots of products or contracts having dependency on the API. This way of creating a secondary query would not break any other dependency.
Author Checklist
All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.
I have...
!
to the type prefix if API or client breaking changeCHANGELOG.md
Reviewers Checklist
All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.
I have...
!
in the type prefix if API or client breaking change