-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
[HUDI-4396] Add a boolean parameter to decide whether the partition is cascade or not when hive table columns changes #6139
Conversation
@hudi-bot |
@yihua could you help me review this pr? thanks. |
@hudi-bot run azure |
@Parameter(names = {"--partition-cascade"}, description = "Partition cascade when table columns change.") | ||
public Boolean partitionCascade; |
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.
in general we should avoid adding parameters/configs to tweak the logic inside the sync. There are so many configs already exposing the impl. details and making meta sync hard to use.
For this logic of determining cascade, can you figure out a way to detect it from schema/column changes?
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.
Hi, good idea about the configs settings.
And the logic cascade could not be detected from schema/column changes as far as I think, but the table parameters might help set this config in my opinion, then the user needs to create/alter the table with TBLPROPERTIES: "hoodie.datasource.hive_sync.partition_cascade=false" through HiveSQL, and this is not directly to use.
If we compare these two plans, I prefer the original plan, then what's your opinion?
What is the purpose of the pull request
Add a boolean parameter to decide whether the partition is cascade or not when hive table columns changes
Brief change log
Verify this pull request
This pull request is already covered by existing tests, the default value of the the parameter is true
Committer checklist
Has a corresponding JIRA in PR title & commit
Commit message is descriptive of the change
CI is green
Necessary doc changes done or have another open PR
For large changes, please consider breaking it into sub-tasks under an umbrella JIRA.