[PHOENIX-3357] Issue with column re-ordering in column family support for Calcite-Phoenix

• Type: Sub-task
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Labels: calcite
• Assignee: Wei Xue
• Reporter: Wei Xue
• Created: 06/Oct/16 19:33
• Updated: 09/Jan/17 17:36
• Resolved: 09/Jan/17 17:36

Description

Found another issue here. Right now we re-order our columns so that columns from the same family can be grouped together and that column family can be taken as a structured type. So OrderByIT, there's a test regression in https://builds.apache.org/job/Phoenix-calcite/20/#showFailuresLink, because it has a table definition like:

CREATE TABLE t
  (a_string varchar not null, cf1.a integer, cf1.b varchar, col1 integer, cf2.c varchar, cf2.d integer, col2 integer
  CONSTRAINT pk PRIMARY KEY (a_string))

So when we implement PhoenixTable.getRowType(), the table definition is actually changed from "a_string, cf1.a, cf1.b, col1, cf2.c, cf2.d, col2" into "a_string, cf1.a, cf1.b, col1, col2 cf2.c, cf2.d". As a result "UPSERT INTO T" expects a different column order (data type order) for parameters, and we got an Exception. This happens just because the column re-ordering and has nothing to do with the changes for PHOENIX-2679 yet. UPSERT will get more complicated once we apply PHOENIX-2679 changes, which means there's more work to do for UPSERT for column family support. But regarding this problem alone, would you think it would make sense to add a check in Phoenix DDL that requires users to put column definitions from the same family together, like in this case, only allows "a_string, cf1.a, cf1.b, col1, col2 cf2.c, cf2.d", jamestaylor?

Issue Links

• depends upon: CALCITE-1426 Support customized star expansion in Table
• is depended upon by: PHOENIX-3579 INSERT/UPSERT should allow values less than number of columns in Calcite-Phoenix