subject:"ROW_TIMESTAMP weird behaviour"

Re: ROW_TIMESTAMP weird behaviour

2017-03-20 Thread NaHeon Kim

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 used! : )

Regards,
NaHeon

On 2017-02-07 23:45 (+0900), Ankit Singhal  wrote: 
> 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  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> 
> > dhavalmod...@gmail.com> 
> >> 
> > On 7 February 2017 at 15:28, Ankit Singhal > 
> > 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 > 
> >> 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> 
> >>> dhavalmod...@gmail.com> 
>  
> >>> On 7 February 2017 at 13:18, Pedro Boado  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"  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> 
> > dhavalmod...@gmail.com> 
> >> 
> > 
>  
> >>> 
> >> 
>

Re: ROW_TIMESTAMP weird behaviour

2017-02-07 Thread Dhaval Modi

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
dhavalmod...@gmail.com

On 7 February 2017 at 15:28, Ankit Singhal  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 
> 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
>> dhavalmod...@gmail.com
>>
>> On 7 February 2017 at 13:18, Pedro Boado  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"  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
 dhavalmod...@gmail.com

>>>
>>
>

Re: ROW_TIMESTAMP weird behaviour

2017-02-07 Thread Ankit Singhal

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. '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 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 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
>>> dhavalmod...@gmail.com
>>>
>>
>

Re: ROW_TIMESTAMP weird behaviour

2017-02-07 Thread Dhaval Modi

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 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 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
>> dhavalmod...@gmail.com
>>
>

Re: ROW_TIMESTAMP weird behaviour

2017-02-06 Thread Pedro Boado

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 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
> dhavalmod...@gmail.com
>

ROW_TIMESTAMP weird behaviour

2017-02-06 Thread Dhaval Modi

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
dhavalmod...@gmail.com

Re: ROW_TIMESTAMP weird behaviour

Re: ROW_TIMESTAMP weird behaviour

Re: ROW_TIMESTAMP weird behaviour

Re: ROW_TIMESTAMP weird behaviour

Re: ROW_TIMESTAMP weird behaviour

ROW_TIMESTAMP weird behaviour

6 matches

Site Navigation

Mail list logo

Footer information