Major Description
This issue was found by Gunnar Tapper and Carol Pearson.
With HBase format Trafodion tables (each column in a row is a separate Cell), if the first column in the table can be defaulted, then uniqueness violations are not raised as expected for INSERT statements. Here is an example
create table def1 (c1 int, c2 int not null, c3 int, primary key (c2)) attributes hbase format;
insert into def1 (c2) values (1);
– raises unique constraint error as expected
insert into def1 (c2, c3) values (1,3);
– does not raise constraint error
insert into def1 (c1, c2) values (1,1);
The problem is that during the checkAndPut for INSERTcall we are specifying the column to be checked as the one that has index 0 in the row being inserted. This would the first column being inserted into for the row, as specified by DDL, once omitted columns are removed. Columns with default value could be omitted in a given INSERT, if they are not part of the clustering key.
The fix utilizes that fact that clustering key columns are always present in the row being inserted, even if they can be defaulted and not explicitly in the INSERT statement. We now pass in the index of the first clustering key column, in the row being inserted, to the java layer. The java layer will get the column name/qualifier from the java byte buffer version of row being inserted and use it in the CheckAndPut call. Not that the index of first clustering key column will depend on both which default columns are being skipped and order of columns in DDL. This index does not depend only on DDL.
With the change we get the expected error
>>insert into def1 (c1, c2) values (1,1);
-
-
- ERROR[8102] The operation is prevented by a unique constraint.
-
— 0 row(s) inserted.
>>insert into def1 (c2, c1) values (51,1);
— 1 row(s) inserted.
>>insert into def1 (c2, c1) values (1,51);
-
-
- ERROR[8102] The operation is prevented by a unique constraint.
-
— 0 row(s) inserted.
Attachments
Issue Links
- links to
