You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@phoenix.apache.org by "Maryann Xue (JIRA)" <ji...@apache.org> on 2017/01/09 17:36:58 UTC

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

     [ https://issues.apache.org/jira/browse/PHOENIX-3357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Maryann Xue resolved PHOENIX-3357.
----------------------------------
    Resolution: Fixed

This has been fixed by CALCITE-1425

> Issue with column re-ordering in column family support for Calcite-Phoenix
> --------------------------------------------------------------------------
>
>                 Key: PHOENIX-3357
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-3357
>             Project: Phoenix
>          Issue Type: Sub-task
>            Reporter: Maryann Xue
>            Assignee: Maryann Xue
>              Labels: calcite
>
> 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:
> {code}
> 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))
> {code}
> 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]?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)