[
https://issues.apache.org/jira/browse/HIVE-8527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Zanter resolved HIVE-8527.
--------------------------------
Resolution: Fixed
Fix Version/s: 1.1.0
I can verify that this is fixed in Hive version 1.1.0. (may have been fixed
earlier than that as well.)
Seems to have been fixed by the same thing that fixed HIVE-8297.
> Incorrect TIMESTAMP result on JDBC direct read when next row has no (null)
> value for the TIMESTAMP
> --------------------------------------------------------------------------------------------------
>
> Key: HIVE-8527
> URL: https://issues.apache.org/jira/browse/HIVE-8527
> Project: Hive
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 0.13.0
> Environment: Linux
> Reporter: Doug Sedlak
> Fix For: 1.1.0
>
>
> For the case:
> SELECT * FROM [table]
> JDBC direct reads the table backing data, versus cranking up a MR and
> creating a result set. This report is another direct read JDBC issue with
> TIMESTAMPS, see HIVE-8297 also.
> As in title, a succeeding row with no value corrupts the value read for the
> current row. To reproduce using beeline:
> 1) Create this file as follows in HDFS.
> $ cat > /tmp/ts2.txt
> 2014-09-28 00:00:00,2014-09-28 00:00:00,
> ,,
> <ctrl-D>
> $ hadoop fs -copyFromLocal /tmp/ts2.txt /tmp/ts2.txt
> 2) In beeline load above HDFS data to a TEXTFILE table:
> $ beeline
> > !connect jdbc:hive2://<host>:<port>/<db> hive pass
> org.apache.hive.jdbc.HiveDriver
> > drop table `TIMESTAMP_TEXT2`;
> > CREATE TABLE `TIMESTAMP_TEXT2` (`ts1` TIMESTAMP, `ts2` TIMESTAMP) ROW
> FORMAT DELIMITED FIELDS TERMINATED BY '\054' LINES TERMINATED BY '\012'
> STORED AS TEXTFILE;
> > LOAD DATA INPATH '/tmp/ts2.txt' OVERWRITE INTO TABLE
> `TIMESTAMP_TEXT2`;
> 3) To demonstrate the corrupt data read, in beeline:
> > select * from `TIMESTAMP_TEXT2`;
> Note 1: The incorrect conduct demonstrated above replicates with a standalone
> Java/JDBC program.
> Note 2: Don't know if this is an issue with any other data types, also don't
> know what releases affected, however this occurs in Hive 13. Hive CLI works
> fine. Also works fine if you force a MR:
> select * from `TIMESTAMP_TEXT2` where 1=1;
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
