Phoenix使用ROW_TIMESTAMP字段导致无法从null更新数据的故障描述

版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

本文链接：https://blog.csdn.net/sunlen/article/details/102969851

在使用Phoenix的过程中，发现了一个奇怪的异常现象，其中一个表，有个字段（VARCHAR类型），一旦这个字段被更新为null值，从此就无法重新更新该字段的值。

我在测试过程中，重新新建一张表，就发现可以正常更新，是我困惑不已。

最后经过反复对比，发现是另外一个字段设置成ROW_TIMESTAMP导致的，下面详细讲述一些问题的复习。

目前测试发现问题的Phoenix版本为4.14.0，另外，我在阿里云的5.2.0版本上测试，也同样发现该问题。

先来讲一下正常的逻辑情况。

首先我们先建立一个测试表，语句如下：

CREATE TABLE hyy_test_1(

f_index CHAR(2) not null,

f_create_time date not null,

f_content VARCHAR,

constraint pk primary key(f_index, f_create_time)

)

SALT_BUCKETS = 20;

注意一下，这里的f_create_time是主键，但没有设置为ROW_TIMESTAMP类型，f_content就是我们要测试的VARCHAR字段。

接下来，我们往该表加一条有值的数据，语句如下：

upsert into hyy_test_1(f_index, f_create_time, f_content) values('1', '2019-11-07 14:01:37','哈哈哈');

查询表数据，发现数据正常插入：

接下来重新把f_content赋值为null，发现正常更新：

接下来重新给f_content赋值为非null的值，发现也正常更新了：

到这里，说明数据的更新完全正常，下面我们稍微修改一个表结构，将f_create_time修改为ROW_TIMESTAMP类型，建表语句如下：

CREATE TABLE hyy_test_2(

f_index CHAR(2) not null,

f_create_time date not null,

f_content VARCHAR,

constraint pk primary key(f_index, f_create_time ROW_TIMESTAMP)

)

SALT_BUCKETS = 20;

给表新增一条f_content为空的数据，可以正常新增：

将f_content更新为null，数据可以正常更新：

重新将f_content更新为非空数据，神奇的现象出现了，数据无法更新：

由此可以看出，因为ROW_TIMESTAMP的原因，导致了该问题，目前Phoenix对ROW_TIMESTAMP实现不是太好，里面坑很多。而且，实际上，这个实现作用并不大，很容易就可以替换掉，建议不要使用该方式。