-
Notifications
You must be signed in to change notification settings - Fork 29k
[SPARK-44064][CORE][SQL] Add a new apply function to NonFateSharingCache
#41654
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
Conversation
|
friendly ping @HyukjinKwon @dongjoon-hyun , I want to use this one instead of #41622 |
HyukjinKwon
left a comment
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 am good with this but let's wait for the author's feedback.
|
Thanks @HyukjinKwon for your review, friendly ping @JoshRosen @liuzqt |
Could you explain why you favor the more complex approach that changes prod code to address a test-only issue? All else being equal, the other PR should merge because it's a lot simpler. |
|
I do't mind either this or #41622. I think the main reason is to keep |
|
+1, Agree with what @HyukjinKwon said |
|
Hi @LuciferYang , thanks for the fix! I'm fine with either option. |
|
Thanks @liuzqt |
I rebase the code to make GA test this one again. @HyukjinKwon seems the author approves of this fix. I am planning to merge this one today, do you think it's ok? |
dongjoon-hyun
left a comment
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.
+1, LGTM. I also agree with @LuciferYang and @HyukjinKwon , and support this PR .
What changes were proposed in this pull request?
This pr add a new
applyfunction toNonFateSharingCacheand changeCodeGeneratorto use the newNonFateSharingCache#applyto makecatalystmodule can test using maven.Why are the changes needed?
SPARK-43300 introduced
NonFateSharingCachetocoremodule and it only used byCodeGeneratorwhich is incatalystmodule.There are two
applyfuncitons inNonFateSharingCacheand the input parameter ofNonFateSharingCache#applyiscom.google.common.cache.Cache/LoadingCache.The
catalystmodule may use shaded spark-core jar when we do maven testing and in the shaded spark-core jar, the Guava related classes will be relocated fromcom.google.commontoorg.sparkproject.guava, so the input parameter ofNonFateSharingCache#applywill change toorg.sparkproject.guava.cache.Cache/LoadingCache, but the catalyst module has not been shaded yet when do maven testing, soCodeGeneratorwill still use typecom.google.common.cache.Cacheto call theNonFateSharingCache#applyfunction, then this will result in a mismatch of input types when do maven testing and maven test will aborted as follows:So this pr add a new
applyfunction to break non-core modules directly using Guava Cache related types as input parameter to invokeNonFateSharingCache#applyfunction for workaround, this way can avoid non-core modules Maven test failures caused by using shaded core module.Does this PR introduce any user-facing change?
No
How was this patch tested?
Before
After