-
Notifications
You must be signed in to change notification settings - Fork 28.6k
[SPARK-30765][SQL] Refine base operator abstraction code style #27511
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
ok to test |
Test build #118101 has finished for PR 27511 at commit
|
partitionSpec: Seq[Expression], | ||
orderSpec: Seq[SortOrder], | ||
override val windowExpression: Seq[NamedExpression], | ||
override val partitionSpec: Seq[Expression], |
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 override val
required 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.
same question. case class
means everything is val
so this is just adding override
.
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.
@HyukjinKwon @cloud-fan Thanks! I dropped most changes based on this comment #27368 (comment). So current refactor rules are:
- If abstract class or trait defined with
def
, then no override needed in derived class. - Change
HashJoin
definition todef
to avoidoverride
in derived classes. - Remove abstract class constructer part of
EvalPythonExec
WindowExecBase
to sync with other operator code style.
Test build #118240 has finished for PR 27511 at commit
|
Test build #118245 has finished for PR 27511 at commit
|
Test build #118239 has finished for PR 27511 at commit
|
Test build #118242 has finished for PR 27511 at commit
|
sql/core/src/main/scala/org/apache/spark/sql/execution/window/WindowExecBase.scala
Outdated
Show resolved
Hide resolved
Looks fine now and I'll leave this to the others. @gatorsmile @cloud-fan @HyukjinKwon |
e8a6a4e
to
d07cc1b
Compare
Test build #118272 has finished for PR 27511 at commit
|
partitionSpec: Seq[Expression], | ||
orderSpec: Seq[SortOrder], | ||
child: SparkPlan) extends UnaryExecNode { | ||
abstract class WindowExecBase extends UnaryExecNode { |
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 think we can switch it to trait
now.
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 see, updated in 364f5a7. Thanks!
@@ -57,8 +57,9 @@ import org.apache.spark.util.Utils | |||
* there should be always some rows buffered in the socket or Python process, so the pulling from | |||
* RowQueue ALWAYS happened after pushing into it. | |||
*/ | |||
abstract class EvalPythonExec(udfs: Seq[PythonUDF], resultAttrs: Seq[Attribute], child: SparkPlan) | |||
extends UnaryExecNode { | |||
abstract class EvalPythonExec extends UnaryExecNode { |
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.
This one too. seems we can switch to trait.
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.
Updated in 364f5a7, thanks!
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.
Looks good to me too otherwise.
@@ -102,7 +102,7 @@ case class RowDataSourceScanExec( | |||
filters: Set[Filter], | |||
handledFilters: Set[Filter], | |||
rdd: RDD[InternalRow], | |||
@transient relation: BaseRelation, | |||
@transient override val relation: BaseRelation, |
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.
do we need override
?
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.
Oh, I think I forgot to update here. Per previous discussion, we should replace base definition to 'def' instead of adding these override
s.
@@ -158,7 +158,7 @@ case class RowDataSourceScanExec( | |||
* @param tableIdentifier identifier for the table in the metastore. | |||
*/ | |||
case class FileSourceScanExec( | |||
@transient relation: HadoopFsRelation, | |||
@transient override val relation: HadoopFsRelation, |
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.
ditto
Test build #118919 has finished for PR 27511 at commit
|
Test build #118925 has finished for PR 27511 at commit
|
Merged to master. |
Thanks a lot! @HyukjinKwon @cloud-fan @maropu |
### What changes were proposed in this pull request? When doing base operator abstraction work, we found there are still some code snippet is inconsistent with other abstraction code style. This PR addressed following two code refactor cases. **Case 1** Override keyword missed for some fields in derived classes. The compiler will not capture it if we rename some fields in the future. **Case 2** Inconsistent abstract class field definition. The updated style will simplify derived class definition, e.g. `EvalPythonExec` `WindowExecBase` ### Why are the changes needed? Improve the code style consistency and code quality ### Does this PR introduce any user-facing change? No ### How was this patch tested? Existing tests Closes apache#27511 from Eric5553/BaseClassAbstraction. Authored-by: Eric Wu <492960551@qq.com> Signed-off-by: HyukjinKwon <gurwls223@apache.org>
What changes were proposed in this pull request?
When doing base operator abstraction work, we found there are still some code snippet is inconsistent with other abstraction code style. This PR addressed following two code refactor cases.
Case 1 Override keyword missed for some fields in derived classes. The compiler will not capture it if we rename some fields in the future.
Case 2 Inconsistent abstract class field definition. The updated style will simplify derived class definition, e.g.
EvalPythonExec
WindowExecBase
Why are the changes needed?
Improve the code style consistency and code quality
Does this PR introduce any user-facing change?
No
How was this patch tested?
Existing tests