-
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
feat(orm): specify generic gRPC query service #11791
Conversation
Codecov Report
@@ Coverage Diff @@
## main #11791 +/- ##
==========================================
+ Coverage 66.14% 66.18% +0.03%
==========================================
Files 673 708 +35
Lines 71160 74055 +2895
==========================================
+ Hits 47072 49016 +1944
- Misses 21444 22127 +683
- Partials 2644 2912 +268
|
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.
lgtm! exciting 💯
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 seems great to me!
Then JS libraries can build better direct interfaces on top of these ORM queries
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.
left 2 suggestions
message GetResponse { | ||
|
||
// result is the result of the get query. If no value is found, the gRPC | ||
// status code NOT_FOUND will be returned. |
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 if a wrong index is used? I think we should return InvalidRequst
in that case.
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
|
||
// pagination is the pagination request. | ||
cosmos.base.query.v1beta1.PageRequest pagination = 5; | ||
|
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 adding reverse
flag?
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.
PageRequest already includes reverse
I'd like to move this to cosmos.orm.query.v1 to version it separately. Any objections to that? |
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 actually thinking of simplying the API and removing IndexValue
and maybe the query
oneof
, and using string (proto JSON encoding) instead.
I'm trying to think of gRPC gateway usage. Consider (the current format):
{"message_name":"cosmos.bank.v1.Balance","index":"address,denom","query":{"prefix":{"values":[{"str":"cosmos34sdgihi"}]}}}
vs
{"message_name":"cosmos.bank.v1.Balance","index":"address,denom","prefix":["cosmos34sdgihi"]}
Any objections?
// values are the values of the fields corresponding to the requested index. | ||
// There must be as many values provided as there are fields in the index and | ||
// these values must correspond to the index field types. | ||
repeated IndexValue values = 3; |
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.
repeated IndexValue values = 3; | |
repeated string values = 3; |
oneof query { | ||
|
||
// prefix defines a prefix query. | ||
Prefix prefix = 3; | ||
|
||
// range defines a range query. | ||
Range range = 4; | ||
} |
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.
oneof query { | |
// prefix defines a prefix query. | |
Prefix prefix = 3; | |
// range defines a range query. | |
Range range = 4; | |
} | |
repeated string prefix = 3; | |
repeated string start = 4; | |
repeated string end = 5; |
I'm now thinking of maybe not taking this approach and instead going with logical queries, see #11774 (comment) and #11822 |
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
@aaronc is it okay to merge this then come back? |
I'd want to mark it as alpha first |
Marked as v1alpha1 for now and going to merge. I think this may still be relevant as a very basic layer to sit under other tools as I mentioned here: #11822 (comment) |
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.
Fa
M
Description
Ref #11774
This proposes a generic gRPC query service that uses direct index access and can basically be implemented as a thin layer directly on top of
ormtable.Table
. There is relatively little code required to implement this but it can potentially provide a lot of value as a way to expose queries to basically everything that's using the ORM without needing to implement any custom gRPC queries.A version of this which is type safe is also proposed in #11774 but that would require additional codegen of .proto files. #11774 also proposes a logical query layer instead of direct index access but that's substantially more code to do even naively and an optimized version would take more effort.
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