[
https://issues.apache.org/jira/browse/HIVE-25306?focusedWorklogId=626181&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-626181
]
ASF GitHub Bot logged work on HIVE-25306:
-----------------------------------------
Author: ASF GitHub Bot
Created on: 21/Jul/21 15:13
Start Date: 21/Jul/21 15:13
Worklog Time Spent: 10m
Work Description: zabetak commented on a change in pull request #2445:
URL: https://github.com/apache/hive/pull/2445#discussion_r673845756
##########
File path: common/src/test/org/apache/hive/common/util/TestTimestampParser.java
##########
@@ -47,12 +47,18 @@ public void testDefault() {
Assert.assertEquals(Timestamp.valueOf("1945-12-31T23:59:59"),
tsp.parseTimestamp("1945-12-31 23:59:59"));
+
}
- @Test(expected = IllegalArgumentException.class)
+ @Test
public void testDefaultInvalid() {
final TimestampParser tsp = new TimestampParser();
- tsp.parseTimestamp("12345");
+ Assert.assertEquals(null, tsp.parseTimestamp("12345"));
+ Assert.assertEquals(null, tsp.parseTimestamp("1945-12-45 23:59:59"));
+ Assert.assertEquals(null, tsp.parseTimestamp("1945-15-20 23:59:59"));
+ Assert.assertEquals(null, tsp.parseTimestamp("0000-00-00 00:00:00"));
+ Assert.assertEquals(null, tsp.parseTimestamp(""));
+ Assert.assertEquals(null, tsp.parseTimestamp("null"));
Review comment:
`assertEquals` -> `assertNull`
##########
File path: common/src/java/org/apache/hive/common/util/TimestampParser.java
##########
@@ -191,7 +190,13 @@ public Timestamp parseTimestamp(final String text)
LOG.debug("Could not parse timestamp text: {}", text);
}
}
- return Timestamp.valueOf(text);
+ Timestamp timestamp = null;
+ try {
+ timestamp = Timestamp.valueOf(text);
+ } catch (IllegalArgumentException e) {
+ LOG.info(e.getMessage());
Review comment:
Do we need to LOG this exception? I have the impression that when this
method returns null we will generate an log message anyways. Moreover, I think
that logging at INFO level may be a bit too much for something that seems to be
in the regular control flow.
##########
File path: common/src/test/org/apache/hive/common/util/TestTimestampParser.java
##########
@@ -25,7 +25,7 @@
/**
* Test suite for parsing timestamps.
*/
-public class TestTimestampParser {
+public class TestTimestampParser {
Review comment:
Nit: Extra space
##########
File path:
ql/src/test/org/apache/hadoop/hive/ql/udf/generic/TestGenericUDFAddMonths.java
##########
@@ -173,8 +173,8 @@ public void testWrongDateStr() throws HiveException {
ObjectInspector[] arguments = { valueOI0, valueOI1 };
udf.initialize(arguments);
- runAndVerify("2014-02-30", 1, "2014-04-02", udf);
- runAndVerify("2014-02-32", 1, "2014-04-04", udf);
+ runAndVerify("2014-02-30", 1, null, udf);
+ runAndVerify("2014-02-32", 1, null, udf);
Review comment:
Worth adding a comment that this behavior is also compatible with MySQL:
```
SELECT DATE_ADD('2014-02-30',INTERVAL 1 MONTH);
+-----------------------------------------+
| DATE_ADD('2014-02-30',INTERVAL 1 MONTH) |
+-----------------------------------------+
| NULL |
+-----------------------------------------+
1 row in set, 1 warning (0.00 sec)
```
Moreover it is good to mention in the JIRA which UDFs are impacted by the
change in this PR and update the
[wiki|https://cwiki.apache.org/confluence/display/hive/languagemanual+udf]
accordingly.
##########
File path:
serde/src/java/org/apache/hadoop/hive/serde2/objectinspector/primitive/PrimitiveObjectInspectorUtils.java
##########
@@ -1254,9 +1260,13 @@ public static Timestamp getTimestampFromString(String s)
{
s = s.trim();
s = trimNanoTimestamp(s);
+ if(StringUtils.isEmpty(s))
+ return null;
+
try {
return TimestampUtils.stringToTimestamp(s);
- } catch (IllegalArgumentException e) {
+ } catch (IllegalArgumentException | DateTimeException e) {
+ LOG.info("cannot parse datetime : {}", s);
Review comment:
Logging at INFO level may be too much. I would consider WARN, DEBUG, or
remove the line altogether.
##########
File path:
ql/src/test/results/clientpositive/llap/probedecode_mapjoin_stats.q.out
##########
@@ -416,4 +416,4 @@ POSTHOOK: Input: default@orders_fact
POSTHOOK: Input: default@seller_dim
#### A masked pattern was here ####
101 101 12345 12345 Seller 1 Item 101 2001-01-30
00:00:00
-104 104 23456 23456 Seller 2 Item 104 2002-03-02
00:00:00
+104 104 23456 23456 Seller 2 Item 104 NULL
Review comment:
Why do we get this NULL value?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: gitbox-unsubscr...@hive.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
-------------------
Worklog Id: (was: 626181)
Time Spent: 2h 10m (was: 2h)
> Move Date and Timestamp parsing from ResolverStyle.LENIENT to
> ResolverStyle.STRICT
> ----------------------------------------------------------------------------------
>
> Key: HIVE-25306
> URL: https://issues.apache.org/jira/browse/HIVE-25306
> Project: Hive
> Issue Type: Bug
> Components: Query Planning, UDF
> Reporter: Ashish Sharma
> Assignee: Ashish Sharma
> Priority: Major
> Labels: pull-request-available
> Attachments: DB_compare.JPG
>
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> Description -
> Currently Date.java and Timestamp.java use DateTimeFormatter for parsing to
> convert the date/timpstamp from int,string,char etc to Date or Timestamp.
> Default DateTimeFormatter which use ResolverStyle.LENIENT which mean date
> like "1992-13-12" is converted to "2000-01-12",
> Moving DateTimeFormatter which use ResolverStyle.STRICT which mean date like
> "1992-13-12" is not be converted instead NULL is return.
> https://docs.google.com/document/d/1YTTPlNq3qyzlKfYVkSl3EFhVQ6-wa9WFRdkdIeCoc1Y/edit?usp=sharing
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
