[
https://issues.apache.org/jira/browse/PHOENIX-2679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maryann Xue updated PHOENIX-2679:
---------------------------------
Comment: was deleted
(was: 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 this patch yet. UPSERT will get more complicated once we apply this
patch, 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]?)
> Implement column family schema structure in Calcite-Phoenix
> -----------------------------------------------------------
>
> Key: PHOENIX-2679
> URL: https://issues.apache.org/jira/browse/PHOENIX-2679
> Project: Phoenix
> Issue Type: Task
> Reporter: Maryann Xue
> Assignee: Maryann Xue
> Labels: calcite
> Attachments: PHOENIX-2679.wip.2.patch, PHOENIX-2679.wip.patch,
> suggested-calcite-changes-for-PHOENIX-2679.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
