Uh oh!
There was an error while loading. Please reload this page.
[SPARK-35288][SQL] StaticInvoke should find the method without exact argument classes match - #32413
[SPARK-35288][SQL] StaticInvoke should find the method without exact argument classes match#32413viirya wants to merge 10 commits into
Conversation
| lazy val argClasses = ScalaReflection.expressionJavaClasses(arguments) | ||
| @transient lazy val method = cls.getDeclaredMethod(functionName, argClasses : _*) | ||
| @transient lazy val method = { |
There was a problem hiding this comment.
This is duplicated with Invoke. But this will be backported, so I will leave the merging of method only to master branch.
There was a problem hiding this comment.
Even though it's for backporting, shall we still avoid duplicated code and add a def findMethod(cls: Class[_]) in the base class?
SparkQA
commented
May 1, 2021
Kubernetes integration test starting |
SparkQA
commented
May 1, 2021
Kubernetes integration test status failure |
| sys.error(s"Couldn't find $functionName on $cls") | ||
| } else if (m.length > 1) { | ||
| // More than one matched method signature. Exclude synthetic one, e.g. generic one. | ||
| val realMethods = m.filter(!_.isSynthetic) |
There was a problem hiding this comment.
This check is needed for the static case, too?
There was a problem hiding this comment.
Just test it. We can remove it.
Uh oh!
There was an error while loading. Please reload this page.
| @transient lazy val method = cls.getDeclaredMethod(functionName, argClasses : _*) | ||
| @transient lazy val method = { | ||
| try { | ||
| cls.getDeclaredMethod(functionName, argClasses: _*) |
There was a problem hiding this comment.
btw, java_method can support more cases via the same resolution logic?
There was a problem hiding this comment.
Took a rough look at how java_method resolves the calling method. java_method only calls Java static method, but StaticInvoke covers Scala object method too. java_method's argument types seem only for catalyst primitive data types, so complext type and ObjectType is not supported.
There was a problem hiding this comment.
We may extend java_method later.
SparkQA
commented
May 2, 2021
Test build #138134 has finished for PR 32413 at commit
|
| val input = (1, 2) | ||
| checkObjectExprEvaluation( | ||
| Invoke(Literal(obj, clsType), "testFunc", IntegerType, Seq(Literal(1))), 0) | ||
| Invoke(Literal(obj, clsType), "testFunc", IntegerType, | ||
| Seq(Literal(input, ObjectType(input.getClass)))), 2) |
There was a problem hiding this comment.
Fix this test from SPARK-35278. Original one doesn't produce synthetic method. I may miss it when I changed the code.
HyukjinKwon
left a comment
There was a problem hiding this comment.
The changes look making sense to me
| // Ambiguous case, we don't know which method to choose, just fail it. | ||
| sys.error(s"Found ${m.length} $functionName on $cls") | ||
| } else { | ||
| m.head |
There was a problem hiding this comment.
I get it, but this may not match. I understand that if I want to pass a String, then a method taking an Object "works" but a method taking a Long does not. Does that just cause other problems, or, are we assuming that because it already fails, we just get a different failure, so whatever? you could inspect the args to see if each isAssignableFrom or something I suppose, but maybe not worth it
There was a problem hiding this comment.
I guess we work best here to find a method for given method name and arguments. For a method taking Object, seems it works to take a String. Adding isAssignableFrom check may work for some cases to catch a failure earily. Although as I test, isAssignableFrom is unable to catch the case if argument class is int and parameter type is Object too.
There was a problem hiding this comment.
As I plan to backport this, for further improvement I will leave for master only. This change is only for the missing case. Is any update I should do for this change?
There was a problem hiding this comment.
I think it's fine to stay conservative for a change you will backport. This will only cause cases that failed completely to possibly work now, right? so I think that's OK.
There was a problem hiding this comment.
I think it's OK for 2.4.8. It will only cause code that failed outright before to possibly succeed, right? that's OK then as a fix.
SparkQA
commented
May 5, 2021
Test build #138155 has finished for PR 32413 at commit
|
SparkQA
commented
May 5, 2021
Kubernetes integration test starting |
SparkQA
commented
May 5, 2021
Kubernetes integration test status failure |
viirya
commented
May 5, 2021
retest this please |
dongjoon-hyun
left a comment
There was a problem hiding this comment.
+1, LGTM. Thank you, @viirya .
SparkQA
commented
May 5, 2021
Kubernetes integration test starting |
SparkQA
commented
May 5, 2021
Kubernetes integration test status failure |
viirya
commented
May 6, 2021
Thanks @dongjoon-hyun@srowen. @maropu@cloud-fan Need to take another look? I may merge this before this week and backport so I can begin to cut RC4 of 2.4.8. |
I think you can merge this, @viirya . All comments seems to be addressed (including this, #32413 (comment)) |
dongjoon-hyun
commented
May 6, 2021
Also, it's okay to wait for @cloud-fan 's comment if this is not that urgent. |
viirya
commented
May 6, 2021
Thanks @dongjoon-hyun@srowen@maropu. Let me wait more a few days. I will merge before the end of this week. |
cloud-fan
commented
May 6, 2021
shall we consider #32404 (comment) ? |
SparkQA
commented
May 6, 2021
Test build #138181 has finished for PR 32413 at commit
|
viirya
commented
May 6, 2021
It looks promising. Do you think we should use it even in backports? Or just use it in master only? |
viirya
commented
May 6, 2021
@cloud-fan If we decide to leave using of the util method in master, this is pretty conservative fix, shall we backport this, and then open new PRs for util method in master? |
cloud-fan
left a comment
There was a problem hiding this comment.
LGTM except for one comment: https://github.com/apache/spark/pull/32413/files#r627148233
viirya
commented
May 7, 2021
Added the shared method. |
viirya
commented
May 7, 2021
Thanks @cloud-fan@dongjoon-hyun. I will merge once CI passes. |
SparkQA
commented
May 7, 2021
Kubernetes integration test starting |
SparkQA
commented
May 7, 2021
Kubernetes integration test status failure |
SparkQA
commented
May 7, 2021
Test build #138230 has finished for PR 32413 at commit
|
viirya
commented
May 7, 2021
Thanks al! Merging to master/3.1/3.0/2.4. |
…argument classes match ### What changes were proposed in this pull request? This patch proposes to make StaticInvoke able to find method with given method name even the parameter types do not exactly match to argument classes. ### Why are the changes needed? Unlike `Invoke`, `StaticInvoke` only tries to get the method with exact argument classes. If the calling method's parameter types are not exactly matched with the argument classes, `StaticInvoke` cannot find the method. `StaticInvoke` should be able to find the method under the cases too. ### Does this PR introduce _any_ user-facing change? Yes. `StaticInvoke` can find a method even the argument classes are not exactly matched. ### How was this patch tested? Unit test. Closes#32413 from viirya/static-invoke. Authored-by: Liang-Chi Hsieh <viirya@gmail.com> Signed-off-by: Liang-Chi Hsieh <viirya@gmail.com> (cherry picked from commit 33fbf56) Signed-off-by: Liang-Chi Hsieh <viirya@gmail.com>
…argument classes match ### What changes were proposed in this pull request? This patch proposes to make StaticInvoke able to find method with given method name even the parameter types do not exactly match to argument classes. ### Why are the changes needed? Unlike `Invoke`, `StaticInvoke` only tries to get the method with exact argument classes. If the calling method's parameter types are not exactly matched with the argument classes, `StaticInvoke` cannot find the method. `StaticInvoke` should be able to find the method under the cases too. ### Does this PR introduce _any_ user-facing change? Yes. `StaticInvoke` can find a method even the argument classes are not exactly matched. ### How was this patch tested? Unit test. Closes#32413 from viirya/static-invoke. Authored-by: Liang-Chi Hsieh <viirya@gmail.com> Signed-off-by: Liang-Chi Hsieh <viirya@gmail.com> (cherry picked from commit 33fbf56) Signed-off-by: Liang-Chi Hsieh <viirya@gmail.com>
…argument classes match ### What changes were proposed in this pull request? This patch proposes to make StaticInvoke able to find method with given method name even the parameter types do not exactly match to argument classes. ### Why are the changes needed? Unlike `Invoke`, `StaticInvoke` only tries to get the method with exact argument classes. If the calling method's parameter types are not exactly matched with the argument classes, `StaticInvoke` cannot find the method. `StaticInvoke` should be able to find the method under the cases too. ### Does this PR introduce _any_ user-facing change? Yes. `StaticInvoke` can find a method even the argument classes are not exactly matched. ### How was this patch tested? Unit test. Closes#32413 from viirya/static-invoke. Authored-by: Liang-Chi Hsieh <viirya@gmail.com> Signed-off-by: Liang-Chi Hsieh <viirya@gmail.com> (cherry picked from commit 33fbf56) Signed-off-by: Liang-Chi Hsieh <viirya@gmail.com>
viirya
commented
May 7, 2021
Then I will prepare a master only PR to use the util method. |
…argument classes match ### What changes were proposed in this pull request? This patch proposes to make StaticInvoke able to find method with given method name even the parameter types do not exactly match to argument classes. ### Why are the changes needed? Unlike `Invoke`, `StaticInvoke` only tries to get the method with exact argument classes. If the calling method's parameter types are not exactly matched with the argument classes, `StaticInvoke` cannot find the method. `StaticInvoke` should be able to find the method under the cases too. ### Does this PR introduce _any_ user-facing change? Yes. `StaticInvoke` can find a method even the argument classes are not exactly matched. ### How was this patch tested? Unit test. Closesapache#32413 from viirya/static-invoke. Authored-by: Liang-Chi Hsieh <viirya@gmail.com> Signed-off-by: Liang-Chi Hsieh <viirya@gmail.com> (cherry picked from commit 33fbf56) Signed-off-by: Liang-Chi Hsieh <viirya@gmail.com>
…argument classes match ### What changes were proposed in this pull request? This patch proposes to make StaticInvoke able to find method with given method name even the parameter types do not exactly match to argument classes. ### Why are the changes needed? Unlike `Invoke`, `StaticInvoke` only tries to get the method with exact argument classes. If the calling method's parameter types are not exactly matched with the argument classes, `StaticInvoke` cannot find the method. `StaticInvoke` should be able to find the method under the cases too. ### Does this PR introduce _any_ user-facing change? Yes. `StaticInvoke` can find a method even the argument classes are not exactly matched. ### How was this patch tested? Unit test. Closesapache#32413 from viirya/static-invoke. Authored-by: Liang-Chi Hsieh <viirya@gmail.com> Signed-off-by: Liang-Chi Hsieh <viirya@gmail.com> (cherry picked from commit 33fbf56) Signed-off-by: Liang-Chi Hsieh <viirya@gmail.com>
What changes were proposed in this pull request?
This patch proposes to make StaticInvoke able to find method with given method name even the parameter types do not exactly match to argument classes.
Why are the changes needed?
Unlike
Invoke,StaticInvokeonly tries to get the method with exact argument classes. If the calling method's parameter types are not exactly matched with the argument classes,StaticInvokecannot find the method.StaticInvokeshould be able to find the method under the cases too.Does this PR introduce any user-facing change?
Yes.
StaticInvokecan find a method even the argument classes are not exactly matched.How was this patch tested?
Unit test.