-
Notifications
You must be signed in to change notification settings - Fork 5.8k
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
improve the usability of DDL Job.Args #53930
Labels
type/enhancement
The issue or PR belongs to an enhancement.
Comments
And for one type of DDL jobs, the For example, DROP DATABASE will have a Lines 685 to 687 in d19fc99
but somehow it becomes Lines 284 to 286 in d19fc99
|
This was referenced Sep 5, 2024
This was referenced Sep 10, 2024
13 tasks
Benjamin2037
pushed a commit
to Benjamin2037/tidb
that referenced
this issue
Sep 11, 2024
This was referenced Sep 11, 2024
13 tasks
13 tasks
13 tasks
13 tasks
This was referenced Sep 20, 2024
13 tasks
This was referenced Sep 23, 2024
winoros
pushed a commit
to winoros/tidb
that referenced
this issue
Sep 23, 2024
winoros
pushed a commit
to winoros/tidb
that referenced
this issue
Sep 23, 2024
13 tasks
13 tasks
13 tasks
13 tasks
13 tasks
13 tasks
This was referenced Sep 30, 2024
13 tasks
13 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Enhancement
Currently Job.Args is like a type-erasure field
tidb/pkg/parser/model/ddl.go
Lines 514 to 522 in fedf3b7
It's hard to find all usage of a DDL job type arguments and maintain them.
idea 1: I think it's better to have a specialized
struct
for each DDL job type. So the developer can directly find all usage of a DDL job type among all types.idea 2: don't change old format of the serialized Job.RawArgs, the new
struct
s should handle the serialization/deserialization in the old format. The advantage is we don't need to handle the compatibility of DDL jobs written by old version clusters.Tasks
The text was updated successfully, but these errors were encountered: