add java client and grpc #949
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| @@ -5,6 +5,8 @@ syntax = "proto3"; | |||
|
|
|||
| package query; | |||
|
|
|||
| option java_package="com.youtube.vitess.grpc.proto"; | |||
There was a problem hiding this comment.
I would put the protos in a non-grp package, like:
com.youtube.vitess.proto
and the service ones for grpc in:
com.youtube.vitess.proto.grpc
|
This is awesome, that was really fast! I think you've done the hard part, the rest is just tweaking it so it's consistent with other implementations, and we're good! |
1. define rules in the Maven build files to compile the data protos at build time. 2. define a new vtgate service interface that uses the proto3 data structures and defines an abstract service.
Merged
systay
pushed a commit
to planetscale/vitess
that referenced
this pull request
Aug 19, 2022
…essio#949) * Linter: `go fmt` a comment Signed-off-by: Patrick Reynolds <[email protected]> * Stop marking unnormalized stmts as `<error>` In the first draft of Insights, we unconditionally reported `<error>` as the normalized SQL statement for any reported statement that had an error. But that was too limiting, and we wanted to report SQL statements for errors any time we were reasonably confident they didn't have PII in them. So in 0b35306, we introduced `LogStats.IsNormalized` to indicate that a statement had been normalized successfully. We successfully applied `IsNormalized` to pass along real SQL statements with errors, if those statements had been normalized. Unfortunately, we overdid it and replaced all un-normalized statements with `<error>` whether or not the statement's execution had caused an error! It turns out lots of statements that aren't errors, also aren't normalized. @rafer found the two functions that control that, in vitessio#797. This commit fixes all that. Now we pass a SQL statement in all cases that we know to be normalized, as well as those that we know did not cause an error. We only send `<error>` for statements that are both un-normalized _and_ an error, which was the intent all along. Fixes vitessio#797. Signed-off-by: Patrick Reynolds <[email protected]> * Add some tests Signed-off-by: Patrick Reynolds <[email protected]> * Send raw SQL even if the query wasn't normalized If the user asks for raw queries, we should send them whether or not the queries got normalized. There's no leak or privacy violation once they opt into raw queries. There are two kinds of queries that aren't normalized, and we want raw SQL for both: - statements that don't need to be normalized, like `BEGIN`, or `ROLLBACK` - syntax errors, for which having raw SQL is useful for debugging Signed-off-by: Patrick Reynolds <[email protected]> Signed-off-by: Patrick Reynolds <[email protected]> Signed-off-by: Dirkjan Bussink <[email protected]> Co-authored-by: Dirkjan Bussink <[email protected]>
dbussink
added a commit
that referenced
this pull request
Jan 30, 2023
* Linter: `go fmt` a comment Signed-off-by: Patrick Reynolds <[email protected]> * Stop marking unnormalized stmts as `<error>` In the first draft of Insights, we unconditionally reported `<error>` as the normalized SQL statement for any reported statement that had an error. But that was too limiting, and we wanted to report SQL statements for errors any time we were reasonably confident they didn't have PII in them. So in 0b35306, we introduced `LogStats.IsNormalized` to indicate that a statement had been normalized successfully. We successfully applied `IsNormalized` to pass along real SQL statements with errors, if those statements had been normalized. Unfortunately, we overdid it and replaced all un-normalized statements with `<error>` whether or not the statement's execution had caused an error! It turns out lots of statements that aren't errors, also aren't normalized. @rafer found the two functions that control that, in #797. This commit fixes all that. Now we pass a SQL statement in all cases that we know to be normalized, as well as those that we know did not cause an error. We only send `<error>` for statements that are both un-normalized _and_ an error, which was the intent all along. Fixes #797. Signed-off-by: Patrick Reynolds <[email protected]> * Add some tests Signed-off-by: Patrick Reynolds <[email protected]> * Send raw SQL even if the query wasn't normalized If the user asks for raw queries, we should send them whether or not the queries got normalized. There's no leak or privacy violation once they opt into raw queries. There are two kinds of queries that aren't normalized, and we want raw SQL for both: - statements that don't need to be normalized, like `BEGIN`, or `ROLLBACK` - syntax errors, for which having raw SQL is useful for debugging Signed-off-by: Patrick Reynolds <[email protected]> Signed-off-by: Patrick Reynolds <[email protected]> Signed-off-by: Dirkjan Bussink <[email protected]> Co-authored-by: Dirkjan Bussink <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
defines an abstract service.