-
Notifications
You must be signed in to change notification settings - Fork 28.5k
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
[SPARK-3363][SQL] Type Coercion should support every type to have null value #2246
Conversation
QA tests have started for PR 2246 at commit
|
QA tests have finished for PR 2246 at commit
|
JsonRDD also called HiveTypeCoercion.allPromotion, but with a method owned by itself, which leads to the failure. I have fixed that also. |
QA tests have started for PR 2246 at commit
|
QA tests have finished for PR 2246 at commit
|
// If found return the widest common type, otherwise None | ||
val returnType = applicableConversion.map(_.filter(t => t == t1 || t == t2).last) | ||
// If found return the widest common type, otherwise None | ||
applicableConversion.map(_.filter(t => t == t1 || t == t2).last) |
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.
Is there a reason we can't just call findTightestCommonType
here?
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, in complex type they are different. For example what JSON cares are if the key strings are the same(MapType), which is quite different from here.
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.
Well, yes after this the code is different, but up here this looks identical. Could this just be val returnType = findTightestCommonType(t1, t2)
? (Sorry if I'm missing something obvious)
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.
But I think in the future we should also support complex type promotion in findTightestCommonType(t1, t2)
. Anyway we can extract the current findTightestCommonType(t1, t2)
as a util function. What do you prefer?
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.
Yeah, I don't see any reason to over plan for possible extension in the future. Since this code is the same in both places I think it'd be better to just call findTightestCommonType instead of duplicating it. If we decide to add more rules in the future we can add a new function that calls this simpler version.
01e7a7a
to
46daa90
Compare
I made a mistake here, This part cannot use |
46daa90
to
ef6f986
Compare
QA tests have started for PR 2246 at commit
|
I have changed the code, now |
QA tests have finished for PR 2246 at commit
|
I hate graphx :( |
Don't hate it :) |
Jenkins, retest this please. |
QA tests have started for PR 2246 at commit
|
QA tests have finished for PR 2246 at commit
|
I don't think the concern about using Here is a PR (against your PR) that implements this and seems to pass all our tests: adrian-wang#2 |
Hmm... you are right, I misunderstood some code in |
reduce code duplication
QA tests have started for PR 2246 at commit
|
QA tests have finished for PR 2246 at commit
|
Jenkins, test this please |
QA tests have started for PR 2246 at commit
|
QA tests have finished for PR 2246 at commit
|
The fail is in BroadcastSuite, has nothing to do with this PR... |
@JoshRosen, another flakey one in Core |
Thanks! Merged to master. |
Type Coercion should support every type to have null value