phoenix-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alberto Bengoa <albe...@propus.com.br>
Subject Re: ROW_TIMESTAMP
Date Fri, 02 Feb 2018 21:26:22 GMT
Right. Will do in this way.

Thank you again. :-)


James Taylor wrote
> Yes, I think having your own LAST_UPDATED column would be the best option
> currently.
> 
> On Fri, Feb 2, 2018 at 1:18 PM, Alberto Bengoa &lt;

> alberto@.com

> &gt;
> wrote:
> 
>> Hello James,
>>
>> Thanks for replying.
>>
>> It really seems that PHOENIX-4552 potentially fits to my purpose. I'll
>> track
>> this JIRA to get updates about it.
>>
>> BTW, considering nowadays, there's no option except to update some date
>> type
>> field on client side every upsert?
>>
>> Thank you so much.
>>
>> Alberto
>>
>>
>> James Taylor wrote
>> > Hi Alberto,
>> > Sounds like you need PHOENIX-4552. If you agree, let's continue the
>> > discussion over there.
>> > Thanks,
>> > James
>> >
>> > On Fri, Feb 2, 2018 at 9:05 AM, Alberto Bengoa &lt;
>>
>> > alberto@.com
>>
>> > &gt;
>> > wrote:
>> >
>> >> Hello Folks,
>> >>
>> >> I'm working on a project where we need to identify when a row was
>> changed
>> >> (updated fields). I was wondering if ROW_TIMESTAMP would help me to
>> reach
>> >> this goal.
>> >>
>> >> I created the test table bellow, and inserted some data:
>> >>
>> >> create table test(
>> >>   a integer not null,
>> >>   b integer,
>> >>   last_update date not null
>> >>   CONSTRAINT PK PRIMARY KEY (a, last_update row_timestamp)
>> >> );
>> >>
>> >> upsert into test (a, b) values (1, 1);
>> >> upsert into test (a, b) values (2, 2);
>> >> upsert into test (a, b) values (3, 4);
>> >>
>> >> 0: jdbc:phoenix:> select * from test;
>> >> +----+----+--------------------------+
>> >> | A  | B  |       LAST_UPDATE        |
>> >> +----+----+--------------------------+
>> >> | 1  | 1  | 2018-02-02 16:33:52.345  |
>> >> | 2  | 2  | 2018-02-02 16:33:56.714  |
>> >> | 3  | 4  | 2018-02-02 16:34:00.281  |
>> >> +----+----+--------------------------+
>> >> 3 rows selected (0.041 seconds)
>> >>
>> >> So, I've tried to update B value where A = 3;
>> >>
>> >> 0: jdbc:phoenix:> upsert into test (a, b) values (3, 3);
>> >>
>> >> Then, I have one "new" row, not an updated row as I need:
>> >>
>> >> 0: jdbc:phoenix:> select * from test;
>> >> +----+----+--------------------------+
>> >> | A  | B  |       LAST_UPDATE        |
>> >> +----+----+--------------------------+
>> >> | 1  | 1  | 2018-02-02 16:33:52.345  |
>> >> | 2  | 2  | 2018-02-02 16:33:56.714  |
>> >> | 3  | 4  | 2018-02-02 16:34:00.281  |
>> >> | 3  | 3  | 2018-02-02 16:36:31.890  |
>> >> +----+----+--------------------------+
>> >> 4 rows selected (0.052 seconds)
>> >>
>> >> I understand that LAST_UPDATE column is part of the PRIMARY KEY and,
>> from
>> >> this perspective, it's in fact should be a NEW row. But, on the other
>> >> hand,
>> >> this not fits my case, because actually I'll have a new row after each
>> >> "update" (and I have lots of updates).
>> >>
>> >> There's any alternative to this on the Phoenix side? I was not
>> expecting
>> >> to have to call a now() function from client side all the time to
>> update
>> >> a
>> >> last_update field.
>> >>
>> >> Maybe another kind of CONSTRAINT that would be used?
>> >>
>> >> Phoenix version 4.7 here.
>> >>
>> >> Thanks in advanced!
>> >>
>> >> Cheers,
>> >> Alberto
>> >>
>> >>
>>
>>
>>
>>
>>
>> --
>> Sent from: http://apache-phoenix-user-list.1124778.n5.nabble.com/
>>





--
Sent from: http://apache-phoenix-user-list.1124778.n5.nabble.com/

Mime
View raw message