[SPARK] Config methods simplification at SparkSession#Builder#16823
[SPARK] Config methods simplification at SparkSession#Builder#16823pfcoperez wants to merge 1 commit intoapache:masterfrom pfcoperez:sparksession_buildersimplification
Conversation
|
Can one of the admins verify this patch? |
…g code readibility and reducing the probability of forgeting to propagate changes across methods
|
This is a bad idea! First it breaks backward compatibility, and second, we intentionally didn't want to make it so general that the user can pass in any objects. Can you please close this PR? |
|
Yeah, non-starter I'm afraid. |
|
@andrewor14 @srowen OK, no discussion: I'll close it. Just an observation:
|
|
@andrewor14 @srowen In any case, I just wanted to add that copying code is, basically the worst strategy. If you wanted to constraint the types for those tree and not just AnyVal sub-classes I would recommend doing something as: Exactly same interface, no copy-paste code. |
|
Agree, though we are talking about duplicating 1 line of code in 3 nearby places. It's not meaningfully duplicating anything. |

What changes were proposed in this pull request?
SparkSession' companion objectBuilderinner class presents several implementations for config setter which are exact copies of the same method just varying the value input type.There are setters for
Double,LongandBoolean. And the three of them transform the input value into an string via the default.toStringmethod.These are basic types and, therefore, child classes of
AnyVal. Why explicitly enumerating them in a set of methods replicating code?The
configimplementation forStringvalues can be invoke by a single method.This PR tries to:
SparkSession#BuilderHow was this patch tested?
This PRs changes the implementation of already tested, by the current test suites. Hence, no more testing has been added as no actual functionality is added.