-
Notifications
You must be signed in to change notification settings - Fork 28.6k
[SPARK-29870][SQL][FOLLOW-UP] Keep CalendarInterval's toString #26572
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
cc @cloud-fan and @yaooqinn |
sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/util/IntervalUtils.scala
Outdated
Show resolved
Hide resolved
LGTM, thanks for your follow-up. |
private def appendUnit(sb: StringBuilder, value: Long, unit: String): Unit = { | ||
if (value != 0) sb.append(value).append(' ').append(unit).append(' ') | ||
} | ||
def toMultiUnitsString(interval: CalendarInterval): String = interval.toString |
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.
probably add a comment saying that the toString
implementation is the multi-units format.
Test build #114009 has finished for PR 26572 at commit
|
@@ -119,10 +119,6 @@ private[sql] class JacksonGenerator( | |||
(row: SpecializedGetters, ordinal: Int) => | |||
gen.writeNumber(row.getDouble(ordinal)) | |||
|
|||
case CalendarIntervalType => |
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 doesn't change behavior, right? same string comes out?
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.
Yup, as it will still call toString
.
Last commit is comment-only (eefd457). |
Merged to master. |
What changes were proposed in this pull request?
This is a followup of #26418. This PR removed
CalendarInterval
'stoString
with an unfinished changes.Why are the changes needed?
Ideally we should make each PR isolated and separate targeting one issue without touching unrelated codes.
There are some other places where the string formats were exposed to users. For example:
Such fixes:
can cause performance regression due to type dispatch for each map.
Does this PR introduce any user-facing change?
Yes, see 2. case above.
How was this patch tested?
Manually tested.