It's actually getting added but may be due to timezone difference, your values are going in future. You can set the local time zone by setting phoenix.query.dateFormatTimeZone https://phoenix.apache.org/tuning.html
On Tue, Feb 7, 2017 at 6:34 PM, Dhaval Modi <[email protected]> wrote: > 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 15:02:21.050 | > | 2017-01-02 15:02:21.050 | > | 2017-01-13 15:02:21.050 | > | 2017-02-06 15:02:21.050 | > | 2017-02-07 11:02:21.050 | > | 2017-02-07 11:03:21.050 | > | 2017-02-07 12:02:21.050 | > +--------------------------+ > 7 rows selected (0.044 seconds) > 0: jdbc:phoenix:> upsert into DUMMY values('2017-02-07T*12:03:21.050'*); > 1 row affected (0.01 seconds) > 0: jdbc:phoenix:> select * from DUMMY; > +--------------------------+ > | XXX_TS | > +--------------------------+ > | 2017-01-01 15:02:21.050 | > | 2017-01-02 15:02:21.050 | > | 2017-01-13 15:02:21.050 | > | 2017-02-06 15:02:21.050 | > | 2017-02-07 11:02:21.050 | > | 2017-02-07 11:03:21.050 | > | 2017-02-07 12:02:21.050 | > *| 2017-02-07 12:03:21.050 |* > +--------------------------+ > 8 rows selected (0.047 seconds) > 0: jdbc:phoenix:> upsert into DUMMY values('2017-02-07T*13:03:21.050*'); > 1 row affected (0.009 seconds) > 0: jdbc:phoenix:> select * from DUMMY; > +--------------------------+ > | XXX_TS | > +--------------------------+ > | 2017-01-01 15:02:21.050 | > | 2017-01-02 15:02:21.050 | > | 2017-01-13 15:02:21.050 | > | 2017-02-06 15:02:21.050 | > | 2017-02-07 11:02:21.050 | > | 2017-02-07 11:03:21.050 | > | 2017-02-07 12:02:21.050 | > | 2017-02-07 12:03:21.050 | > +--------------------------+ > 8 rows selected (0.04 seconds) > > > > > > > Regards, > Dhaval Modi > [email protected] > > On 7 February 2017 at 15:28, Ankit Singhal <[email protected]> > wrote: > >> 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 <[email protected]> >> 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. '2017-*01*-02T15:02:21.050' >>> >>> >>> Regards, >>> Dhaval Modi >>> [email protected] >>> >>> On 7 February 2017 at 13:18, Pedro Boado <[email protected]> wrote: >>> >>>> 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" <[email protected]> wrote: >>>> >>>>> 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 values('2017-07-02T15:02:21.050'); >>>>> upsert into DUMMY values('2017-01-02T15:02:21.050'); >>>>> >>>>> I am only seeing one entry. >>>>> *======================================================* >>>>> *0: jdbc:phoenix:> select * from DUMMY;* >>>>> *+--------------------------+* >>>>> *| XXX_TS |* >>>>> *+--------------------------+* >>>>> *| 2017-01-02 15:02:21.050 |* >>>>> *+--------------------------+* >>>>> *1 row selected (0.039 seconds)* >>>>> *======================================================* >>>>> >>>>> >>>>> Additional info: >>>>> System date of HBase & Phoenix: mar feb 7 05:57:37 CET 2017 >>>>> >>>>> >>>>> Regards, >>>>> Dhaval Modi >>>>> [email protected] >>>>> >>>> >>> >> >
