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 < > alberto@.com > > > 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 < >> >> > alberto@.com >> >> > > >> > 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/
