-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
[vtctld] Migrate GetSchema #7346
[vtctld] Migrate GetSchema #7346
Conversation
Signed-off-by: Andrew Mason <[email protected]>
Signed-off-by: Andrew Mason <[email protected]>
Signed-off-by: Andrew Mason <[email protected]>
Signed-off-by: Andrew Mason <[email protected]>
4956ab5
to
da1437c
Compare
👋 I'm going to be pushing some commits to try to debug the plugin registration problem, apologies for the noise. I'll ping when I've fixed the issue. |
…the fake Signed-off-by: Andrew Mason <[email protected]>
7a9444c
to
3ee391b
Compare
Okay @doeg this should be good to go now! Sorry about 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.
This looks so good and a million thank yous again for doing this. 🐶 ✨ I can't wait to add VTExplain!
The implementation looks great. I just have a question about a couple test cases. :')
shouldErr: false, | ||
}, | ||
{ | ||
name: "table names take precedence over table sizes", |
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.
Small question to double check my read of this. 😊
The command/schema.go
implementation throws an error if both are specified. For what it's worth, explicitly erroring when both flags are set seems preferable to (since it's less surprising than) implicit precedence... and I have a feeling that's why you wrote command/schema.go
to error, right?
And I have a feeling that we can't return an error here, and instead have precedence behaviour, because legacy reasons?
To be clear, I think the discrepancy between the two is fine, and what you have is great. I just want to make sure I follow the difference. :)
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 think this isn't about maintaining "legacy" compatibility, but more that the options are fundamentally incompatible with each other. If I could have made the parser itself enforce the mutual exclusion, that would have been my highest preference.
I think there's an argument to be made that the server implementation itself should error in that case (instead of just relying on the CLI to catch it), but I think I would disagree on "be permissive in what you accept" kinds of reasons.
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.
That makes sense! I think the behaviour as you've written it is really well documented, between the protobuf comments + tests, so "surprising" was probably the wrong word. 😆 Thank you for explaining your thoughts; they are always good. :)
} | ||
} | ||
|
||
tests := []*struct { |
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.
(Bah, GitHub didn't save this question + it's the only blocking question I had.)
🙈 I'm sorry to be the bearer of this question, but did you consider test cases for the tables
and/or exclude_tables
parameters?
I'm also wondering if it might be advantageous to mock > 1 tables for these tests.
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.
No because those are passed straight through to the tabletmanagerclient, so testing is that is their problem, 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.
Or I guess, "yes, I considered it; here's why I'm not" to actually answer your question 😂
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.
Ohhh I missed that! That makes sense, thanks.
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
things are coming together nicely :-)
[vtctld] Migrate GetSchema
[vtctld] Migrate GetSchema Signed-off-by: Richard Bailey <[email protected]>
[vtctld] Migrate GetSchema Signed-off-by: Andrew Mason <[email protected]>
Description
This migrates the
GetSchema
vtctl command to a vtctld rpc, and reimplements the old command to use the new RPC under the hood.Example:
Related Issue(s)
Checklist
Deployment Notes
Impacted Areas in Vitess
Components that this PR will affect: