Skip to content

[SPARK-49768][SQL] Provide error conditions for make_date/make_timestamp errors _LEGACY_ERROR_TEMP_2000 #48242

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.

Sign up for GitHub

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

Closed
itholic wants to merge 16 commits into from
Closed

[SPARK-49768][SQL] Provide error conditions for make_date/make_timestamp errors _LEGACY_ERROR_TEMP_2000 #48242

Changes from 1 commit
Commits
Show all changes
16 commits
Select commit Hold shift + click to select a range
e25bfda
[SPARK-49768][SQL] Provide error Conditions for make_date/make_timest…
itholic Sep 25, 2024
a7d8b7e
Rename
itholic Sep 26, 2024
fe025ab
Use existing error message
itholic Sep 26, 2024
57213c3
Merge branch 'master' of https://github.com/apache/spark into SPARK-4…
itholic Sep 26, 2024
c8cb363
Adjusted comments
itholic Sep 30, 2024
b71e185
Regen golden files
itholic Sep 30, 2024
27fea85
fix test
itholic Sep 30, 2024
5bf98fe
switched to INTERNAL_ERROR
itholic Oct 2, 2024
260145e
Added more informations for error message & regen
itholic Oct 2, 2024
3ea12a4
fix test
itholic Oct 2, 2024
72f7834
Merge branch 'master' of https://github.com/apache/spark into SPARK-4…
itholic Oct 3, 2024
60fb678
Adjusted comments
itholic Oct 3, 2024
83dd8e7
Handling the Invalid date error
itholic Oct 3, 2024
5ec18e8
Fix error message format
itholic Oct 3, 2024
7a31955
revert ansiIllegalArgumentError
itholic Oct 3, 2024
6d96a85
raise existing error for default cases
itholic Oct 5, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
raise existing error for default cases
  • Loading branch information
@itholic
itholic committed Oct 5, 2024
commit 6d96a85b1b6944f4f6dc143092a0dde821417c13
8 changes: 8 additions & 0 deletions sql/catalyst/src/main/scala/org/apache/spark/sql/errors/QueryExecutionErrors.scala
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -298,6 +298,14 @@ private[sql] object QueryExecutionErrors extends QueryErrorsBase with ExecutionE
(unit, formattedRange, badValue)
case datePattern(badDate) =>
("DAY", "1 ... 28/31", badDate)
Copy link
Contributor

@mihailomilosevic2001 mihailomilosevic2001 Oct 6, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is really weird message now. The error we are getting here now is totally relentless of leap years. Java library returns special case errors when we have leap years, look at LocalDate.create.

Copy link
Contributor

@mihailomilosevic2001 mihailomilosevic2001 Oct 6, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To clarify, I find it weird that we are removing extra information which java is giving us for free.

case _ =>
throw new SparkDateTimeException(
Copy link
Contributor

@mihailomilosevic2001 mihailomilosevic2001 Oct 6, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@srielau @gengliangwang let's link issues to the proper tickets and not open duplicate tickets. The reason for not having a error condition is that _LEGACY_ERROR_TEMP_#### errors do not show error condition. There is an existing ticket https://issues.apache.org/jira/browse/SPARK-49768 which was made to correct this. Also, could you please use the epic ANSI by default in JIRA if the change is related to ANSI, as this will make us not create multiple PRs/tickets for same issues. Also, @itholic leaving default branch like this does not solve the issue. We need to make sure we assign a proper error condition for all cases, which in this case we are not doing. (Example is if you try february 29th on a non-leap year) Ultimate goal is to remove _LEGACY_ERROR_TEMP_2000. @MaxGekk what do you think? I find it weird to have a method in QueryExecutionErrors throw completely new error just because of the error message parsing.

errorClass = "_LEGACY_ERROR_TEMP_2000",
messageParameters = Map(
"message" -> errorMessage,
"ansiConfig" -> toSQLConf(SQLConf.ANSI_ENABLED.key)),
context = Array.empty,
summary = "")
}
Copy link
Member

@MaxGekk MaxGekk Oct 4, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@itholic Do you expect that it should match to both the cases above. What if not? I would add a default case.

Copy link
Member

@MaxGekk MaxGekk Oct 4, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For example, toInstant can raise:

        if (seconds < MIN_SECOND || seconds > MAX_SECOND) {
            throw new DateTimeException("Instant exceeds minimum or maximum instant");
        }

How does your code handles this?

Copy link
Contributor Author

@itholic itholic Oct 5, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point.

I think DATETIME_FIELD_OUT_OF_BOUNDS is not very proper error class to cover the example case, so let me leave the existing _LEGACY_ERROR_TEMP_2000 as it is for default case.

We may need introduce several new error classes to cover the all potential exception cases along with more test cases in a separate ticket.

}
val (unit, range, badValue) = extractDateTimeErrorInfo(e)
Expand Down