[
https://issues.apache.org/jira/browse/PHOENIX-6807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17615487#comment-17615487
]
Tanuj Khurana edited comment on PHOENIX-6807 at 10/11/22 6:02 AM:
------------------------------------------------------------------
[~gjacoby] For data tables, we never store timestamps on disk explicitly.
Whenever this function is called, we just return the timestamp of the hbase
cell corresponding to the empty column so there shouldn't be any backward
compatibility concerns. Again, this function is implemented entirely on the
client side so there is no client/server compatibility issue too.
It is also possible to create indexes on PHOENIX_ROW_TIMESTAMP PHOENIX-6434 I
am not sure how widely used that feature is and we can always drop and recreate
the index.
was (Author: tkhurana):
[~gjacoby] For data tables, we never store timestamps on disk explicitly.
Whenever this function is called, we just return the timestamp of the hbase
cell corresponding to the empty column so there shouldn't be any backward
compatibility concerns. Again, this function is implemented entirely on the
client side so there is no client/server compatibility issue too.
It is also possible to create indexes on PHOENIX_ROW_TIMESTAMP [#PHOENIX-6434]
I am not sure how widely used that feature is and we can always drop and
recreate the index.
> Change return type of PHOENIX_ROW_TIMESTAMP() function from DATE -> TIMESTAMP
> -----------------------------------------------------------------------------
>
> Key: PHOENIX-6807
> URL: https://issues.apache.org/jira/browse/PHOENIX-6807
> Project: Phoenix
> Issue Type: Improvement
> Affects Versions: 5.2.0, 5.1.2
> Reporter: Tanuj Khurana
> Assignee: Tanuj Khurana
> Priority: Minor
>
> Today, PHOENIX_ROW_TIMESTAMP() function returns a DATE data type. This causes
> multiple issues:
> {code:java}
> // 0: jdbc:phoenix:localhost> create table T (id varchar primary key, ts
> timestamp);
> No rows affected (0.703 seconds)
> 0: jdbc:phoenix:localhost> upsert into T values('a', TO_TIMESTAMP('2005-10-01
> 14:03:22.559'));
> 1 row affected (0.05 seconds)
> 0: jdbc:phoenix:localhost> upsert into T values('b', TO_TIMESTAMP('2015-09-01
> 23:03:22.559'));
> 1 row affected (0.005 seconds)
> 0: jdbc:phoenix:localhost> upsert into T values('c', TO_TIMESTAMP('2022-09-01
> 03:03:24.897'));
> 1 row affected (0.008 seconds)
> 0: jdbc:phoenix:localhost> !outputformat csv
> 0: jdbc:phoenix:localhost> select ts, PHOENIX_ROW_TIMESTAMP() from T;
> 'TS','PHOENIX_ROW_TIMESTAMP(0.)'
> '2005-10-01 07:03:22.559','2022-10-07'
> '2015-09-01 16:03:22.559','2022-10-07'
> '2022-08-31 20:03:24.897','2022-10-07'
> 3 rows selected (0.012 seconds) {code}
> Notice, how the time component is dropped when we use sqlline to print
> PHOENIX_ROW_TIMESTAMP() values. In comparison, the timestamp column is
> displayed correctly. This is a major drawback IMO since one of the primary
> motivation of implementing the PHOENIX_ROW_TIMESTAMP() function was to aid in
> debugging.
> There is another issue with returning DATE type. Consider the query below:
> {code:java}
> SELECT * from T where PHOENIX_ROW_TIMESTAMP() = <Timestamp value>{code}
> This query always returns 0 rows. This is because the timestamp value which
> is 12 bytes can't be coerced to a DATE type so the where compiler compiles
> the equality expression to an always *FALSE* expression.
> I propose changing the return type of PHOENIX_ROW_TIMESTAMP() to TIMESTAMP.
> It solves both the issues listed above and makes sense since
> PHOENIX_ROW_TIMESTAMP has timestamp in it :)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
