phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Taylor (JIRA)" <>
Subject [jira] [Commented] (PHOENIX-978) Allow views to extend base table's PK (only if last PK column is fixed length)
Date Thu, 09 Jul 2015 04:43:04 GMT


James Taylor commented on PHOENIX-978:

Those aren't rounding errors, [~elilevine]. The base table is reading VIEW_COL1 as the entire
rest of the row key (which would include the value for VIEW_COL2 too). Instead, this ALTER
TABLE should fail, because it's putting the metadata into an invalid state.
            conn.createStatement().execute("ALTER TABLE TABLEWITHVIEW ADD VIEW_COL1 DECIMAL(10,2)
 [~tdsilva] can help you with this or make the change for you. It's the code in MetaDataEndPointImpl.addRowsToChildViews()
- if a view already has the base column being added and the column being added is variable
length and the view has more columns after that, then it's an error. It's a great negative

We should do the positive test too. If the base column being added is fixed length or the
last PK column of the view, then you should be ok.

Probably good to do an ALTER VIEW to add one of the columns to test that code path too.

> Allow views to extend base table's PK (only if last PK column is fixed length)
> ------------------------------------------------------------------------------
>                 Key: PHOENIX-978
>                 URL:
>             Project: Phoenix
>          Issue Type: Sub-task
>    Affects Versions: 3.0.0, 4.0.0
>            Reporter: Eli Levine
>            Assignee: Eli Levine
>             Fix For: 5.0.0, 4.5.0
>         Attachments: PHOENIX-978.diff
> CREATE VIEW syntax currently disallows PK constraint to be defined.  As a result views
and tenant-specific tables created using CREATE VIEW automatically inherit their base table's
PK with no way to extend it.
> Base tables should be allowed to be created with a minimum of PK columns to support views,
and views to extend PKs as desired.  This would allow a single base table to support a heterogeneous
set of views on top of it.

This message was sent by Atlassian JIRA

View raw message