You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hive.apache.org by Apache Jenkins Server <je...@builds.apache.org> on 2012/04/25 23:09:23 UTC
Hive-trunk-h0.21 - Build # 1396 - Fixed
Changes for Build #1391
[cws] HIVE-2928. Support for Oracle-backed Hive-Metastore (longvarchar to clob in package.jdo) (Mithun Radhakrishnan and Andrew Bayer via cws)
[cws] HIVE-2646. Hive Ivy dependencies on Hadoop should depend on jars directly, not tarballs (Andrew Bayer and Thomas Weise)
[hashutosh] HIVE-2970: several jars in hive tar generated are not required (Thejas Nair via Ashutosh Chauhan)
Changes for Build #1392
[cws] HIVE-2803 [jira] utc_from_timestamp and utc_to_timestamp returns incorrect
results.
(Kiyotaka Suzuki via Carl Steinbach)
Summary:
https://issues.apache.org/jira/browse/HIVE-2803
HIVE-2803 utc_from_timestamp and utc_to_timestamp returns incorrect results.
It changed so that applyOffset() return a new instance.
How to reproduce:
$ echo "2011-12-25 09:00:00.123456" > /tmp/data5.txt
hive> create table ts1(t1 timestamp);
hive> load data local inpath '/tmp/data5.txt' overwrite into table ts1;
hive> select t1, from_utc_timestamp(t1, 'JST'), from_utc_timestamp(t1, 'JST')
from ts1 limit 1;
The following result is expected:
2011-12-25 09:00:00.123456 2011-12-25 18:00:00.123456 2011-12-25
18:00:00.123456
However, the above query return incorrect result like this:
2011-12-26 03:00:00.492456 2011-12-26 03:00:00.492456 2011-12-26
03:00:00.492456
This is because GenericUDFFromUtcTimestamp.applyOffset() does setTime()
improperly.
On evaluating query, timestamp argument always returns the same instance.
GenericUDFFromUtcTimestamp.applyOffset() does setTime() on the instance.
That means it adds all offsets in the query.
Test Plan: EMPTY
Reviewers: JIRA
Differential Revision: https://reviews.facebook.net/D1959
[namit] HIVE-2703 ResultSetMetaData.getColumnType() always returns VARCHAR(string) for partition columns
irrespective of partition column type (tamtam180 via namit)
[hashutosh] HIVE-2883 [jira] Metastore client doesnt close connection properly
Summary:
https://issues.apache.org/jira/browse/HIVE-2883
Here is the patch which gets rid of this problem as per my hypothesis. I also
tested it and the above noted stack trace doesnt occur anymore.
While closing connection, it always fail with following trace. Seemingly, it
doesnt have any harmful effects.
12/03/20 10:55:02 ERROR hive.metastore: Unable to shutdown local metastore
client
org.apache.thrift.transport.TTransportException: Cannot write to null
outputStream
at
org.apache.thrift.transport.TIOStreamTransport.write(TIOStreamTransport.java:142)
at
org.apache.thrift.protocol.TBinaryProtocol.writeI32(TBinaryProtocol.java:163)
at
org.apache.thrift.protocol.TBinaryProtocol.writeMessageBegin(TBinaryProtocol.java:91)
at org.apache.thrift.TServiceClient.sendBase(TServiceClient.java:62)
at
com.facebook.fb303.FacebookService$Client.send_shutdown(FacebookService.java:421)
at com.facebook.fb303.FacebookService$Client.shutdown(FacebookService.java:415)
at
org.apache.hadoop.hive.metastore.HiveMetaStoreClient.close(HiveMetaStoreClient.java:310)
Test Plan: EMPTY
Reviewers: JIRA, cwsteinbach
Reviewed By: cwsteinbach
Differential Revision: https://reviews.facebook.net/D2613
Changes for Build #1393
Changes for Build #1394
[cws] HIVE-2976. Fix maven-build Ant target (Thomas Weise and Andrew Bayer via cws)
Changes for Build #1395
[namit] HIVE-2960 Stop testing concat of partitions containing control characters.
(Kevin Wilfong via namit)
Changes for Build #1396
All tests passed
The Apache Jenkins build system has built Hive-trunk-h0.21 (build #1396)
Status: Fixed
Check console output at https://builds.apache.org/job/Hive-trunk-h0.21/1396/ to view the results.