-
Notifications
You must be signed in to change notification settings - Fork 29k
[SPARK-29607][SQL] Move static methods from CalendarInterval to IntervalUtils #26261
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
|
@cloud-fan @HyukjinKwon @dongjoon-hyun Please, take a look at the PR. |
|
Test build #112688 has finished for PR 26261 at commit
|
|
jenkins, retest this, please |
|
Test build #112692 has finished for PR 26261 at commit
|
sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/util/IntervalUtils.scala
Outdated
Show resolved
Hide resolved
sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/util/IntervalUtils.scala
Show resolved
Hide resolved
sql/catalyst/src/test/scala/org/apache/spark/sql/catalyst/util/IntervalUtilsSuite.scala
Outdated
Show resolved
Hide resolved
sql/catalyst/src/test/scala/org/apache/spark/sql/catalyst/util/IntervalUtilsSuite.scala
Outdated
Show resolved
Hide resolved
|
@MaxGekk . I left a few minor comments. In general, the logic is correctly migrated from Java to Scala. And, I agree with @MaxGekk 's opinion. How do you think about this, @cloud-fan ? |
|
Test build #112713 has finished for PR 26261 at commit
|
|
jenkins, retest this, please |
|
Test build #112717 has finished for PR 26261 at commit
|
| } | ||
| } | ||
|
|
||
| private val yearMonthPattern = Pattern.compile("^([+|-])?(\\d+)-(\\d+)$") |
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 can just use Scala regex primitives instead.
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 will require rewriting of dependent code but I wanted to just move methods and keep them closer to original methods as much as possible. Maybe we will refactor the code in a follow up PR?
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.
You're already moving the code and converting to scala in other ways, so I think it's not a big deal to do it here rather than make another one for pretty minor adjustments. Or is there an argument that git won't really track the history of this code after move if it's changed a lot?
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.
To use Scala regexp, I will have to restructure the code significantly, so, it will be impossible to track anything.
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.
Why does it need any restructuring? "...".r gives you an object with pretty much the same API. You don't have to use regex pattern matching in Scala if it's disruptive. Well, I don't feel strongly about it, just doesn't seem any more of a change than you've already made in adapting this code to Scala.
sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/util/IntervalUtils.scala
Outdated
Show resolved
Hide resolved
sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/util/IntervalUtils.scala
Outdated
Show resolved
Hide resolved
sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/util/IntervalUtils.scala
Outdated
Show resolved
Hide resolved
| */ | ||
| private def parseSecondNano(secondNano: String): Long = { | ||
| val parts = secondNano.split("\\.") | ||
| if (parts.length == 1) { |
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.
use a match statement maybe?
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 would do this refactoring in a separate PR too if you don't mind.
|
Test build #112720 has finished for PR 26261 at commit
|
|
Test build #112721 has finished for PR 26261 at commit
|
|
The following failure happens in |
|
jenkins, retest this, please |
| result | ||
| } | ||
|
|
||
| private val yearMonthPattern = "^\\s*([+|-])?(\\d+)-(\\d+)\\s*$".r |
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.
The previous regex does not have the \\s* at the beginning and end. This is because we get the string from parser which already trims the white spaces. Shall we change it back?
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.
Previously, we trim the input explicitly: b482367 . I just trim by the regexp.
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 will revert the regexp and add the assert: assert(input.length == input.trim.length)
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 will do the same in fromDayTimeString()
| s"Cannot support (interval '$s' $from to $to) expression") | ||
| } | ||
| new CalendarInterval(0, sign * ( | ||
| days * DateTimeUtils.MICROS_PER_DAY + hours * MICROS_PER_HOUR + |
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.
inspired by https://github.com/apache/spark/pull/26261/files#diff-eba257f41b49f470321579875f054f00R152 , we should use exact math functions here too. This can be done in a followup.
cloud-fan
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.
LGTM except a minor comment
|
Retest this please. |
|
Test build #112791 has finished for PR 26261 at commit
|
|
Test build #112792 has finished for PR 26261 at commit
|
|
retest this please |
|
Test build #112817 has finished for PR 26261 at commit
|
|
retest this please |
|
Test build #112826 has finished for PR 26261 at commit
|
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.
Looks fine to me too
|
retest this please |
1 similar comment
|
retest this please |
|
Test build #112832 has finished for PR 26261 at commit
|
|
thanks, merging to master! |
|
Thank you all! |
What changes were proposed in this pull request?
In the PR, I propose to move all static methods from the
CalendarIntervalclass to theIntervalUtilsobject. All those methods are rewritten from Java to Scala.Why are the changes needed?
IntervalUtils, see [SPARK-29532][SQL] Simplify interval string parsing #26190CalendarIntervalwill be fully exposed to users in the future (see [SPARK-24695][SQL] MoveCalendarIntervalto org.apache.spark.sql.types package #25022), it would be nice to clean it up by moving service methods to an internal object.Does this PR introduce any user-facing change?
No
How was this patch tested?
CalendarIntervalSuitetoIntervalUtilsSuite