Re: ROW_TIMESTAMP weird behaviour

Hi, Does ‘phoenix.query.dateFormatTimeZone’ work as expected? Though dateFormatTimeZone option and HBase servers are set to UTC+9 timezone, UTC+9 based timestamp values are still hidden. What I expect is that those values are available immediately right after upsert. phoenix-4.8.0-HBase-1.1 is

Re: ROW_TIMESTAMP weird behaviour

Thanks Ankit. My issue is relevant to PHOENIX-3176. But additional observation is, any timestamp value after 13:oo hours of the same day is not added. 0: jdbc:phoenix:> select * from DUMMY; +--+ | XXX_TS | +--+ | 2017-01-01

Re: ROW_TIMESTAMP weird behaviour

I think you are also hitting https://issues.apache.org/jira/browse/PHOENIX-3176. On Tue, Feb 7, 2017 at 2:18 PM, Dhaval Modi wrote: > Hi Pedro, > > Upserted key are different. One key is for July month & other for January > month. > 1. '2017-*07*-02T15:02:21.050' > 2.

Re: ROW_TIMESTAMP weird behaviour

Hi Pedro, Upserted key are different. One key is for July month & other for January month. 1. '2017-*07*-02T15:02:21.050' 2. '2017-*01*-02T15:02:21.050' Regards, Dhaval Modi dhavalmod...@gmail.com On 7 February 2017 at 13:18, Pedro Boado wrote: > Hi. > > I don't think

Re: ROW_TIMESTAMP weird behaviour

Hi. I don't think it's weird. That column is PK and you've upserted twice the same key value so first one is inserted and second one is updated. Regards. On 7 Feb 2017 04:59, "Dhaval Modi" wrote: > Hi All, > > I am facing abnormal scenarios with ROW_TIMESTAMP. > > I

ROW_TIMESTAMP weird behaviour

Hi All, I am facing abnormal scenarios with ROW_TIMESTAMP. I created table in Phoenix as below: CREATE TABLE DUMMY(XXX_TS TIMESTAMP NOT NULL CONSTRAINT pk PRIMARY KEY (XXX_TS ROW_TIMESTAMP)) where "XXX_TS" is used as ROW_TIMESTAMP. Now, I am trying to add data: upsert into DUMMY