0

I am attempting to use Apache Phoenix's filter on timestamp column.

My table and column exists. The column is of type TIMESTAMP. https://phoenix.apache.org/language/datatypes.html#timestamp_type

0: jdbc:phoenix:localhost:2181:/hbase> SELECT * FROM METRIC where METRIC_ID = 'process.cpu' AND METRIC_TIMESTAMP > NOW();
java.lang.NullPointerException
at org.apache.phoenix.compile.ScanRanges.getAscTimeRange(ScanRanges.java:674)

I also tried with CURRENT_TIME()

0: jdbc:phoenix:localhost:2181:/hbase> SELECT * FROM METRIC where METRIC_ID = 'process.cpu' AND METRIC_TIMESTAMP > CURRENT_TIME();
java.lang.NullPointerException
at org.apache.phoenix.compile.ScanRanges.getAscTimeRange(ScanRanges.java:674)
at org.apache.phoenix.compile.ScanRanges.getRowTimestampColumnRange(ScanRanges.java:658)
bearrito
  • 2,217
  • 1
  • 25
  • 36

1 Answers1

0

That's a bug - please file a JIRA. A workaround would be to declare METRIC_TIMESTAMP as a DATE instead of TIMESTAMP. The DATE type in Phoenix has a granularity of millisecond.

James Taylor
  • 206
  • 2
  • 3
  • Will do. I have a similar issue for auto-generated timestamps. – bearrito May 23 '17 at 22:50
  • In order to workaround should I use map the type to sql.Date? Will that maintain granularity to millis? – bearrito May 24 '17 at 01:26
  • In your create table statement declare METRIC_TIMESTAMP to be of type DATE: CREATE TABLE METRIC (...., METRIC_TIMESTAMP DATE). Phoenix uses an 8 byte epoch long to store the date, so it's always at a granularity of millis. Make sure to use a SQL client that shows the full granularity - for example, sqlline only shows the day part of a DATE. You can use SELECT TO_CHAR(METRIC_TIMESTAMP, 'yyyy MM dd HH:mm:ss.SSS') FROM METRIC; – James Taylor May 24 '17 at 23:00