hive-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Dere (JIRA)" <>
Subject [jira] [Commented] (HIVE-9917) After HIVE-3454 is done, make int to timestamp conversion configurable
Date Thu, 02 Apr 2015 23:57:53 GMT


Jason Dere commented on HIVE-9917:

So this is covering the case of converting an int to timestamp where there is an actual cast
operator being used, either explicitly in the query or implicitly added to the query (such
as when inserting integer values into a timestamp column in a table). Not sure if there are
any cases where Hive is implicitly doing the conversion of int to timestamp without an actual
cast operator, I guess you can look at the callers of PrimitiveObjectInpsectors.getTimestamp().
Looking at that, it looks like the Hive-HBase interaction converts timestamps to/from long
values based on millis since epoch, so might want to confirm it's still doing the right thing
here. It's calling getTimestamp() with the old method signature (without the config param),
so I guess that means it is doing the conversion based on the old behavior, which I think
is correct?

Do we have to worry about conversions going the other way - from Timestamp to int/long? Did
that always convert to integer based on seconds, and it was just the int to timestamp conversion
that was inconsistent?

Will defer to [~mmccline] on the vectorization-related changes, though they seem ok. Are there
any times where vectorization does implicit conversion without using the cast operator?

> After HIVE-3454 is done, make int to timestamp conversion configurable
> ----------------------------------------------------------------------
>                 Key: HIVE-9917
>                 URL:
>             Project: Hive
>          Issue Type: Improvement
>            Reporter: Aihua Xu
>            Assignee: Aihua Xu
>         Attachments: HIVE-9917.patch
> After HIVE-3454 is fixed, we will have correct behavior of converting int to timestamp.
While the customers are using such incorrect behavior for so long, better to make it configurable
so that in one release, it will default to old/inconsistent way and the next release will
default to new/consistent way. And then we will deprecate it.

This message was sent by Atlassian JIRA

View raw message