[
https://issues.apache.org/jira/browse/PHOENIX-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15940904#comment-15940904
]
James Taylor commented on PHOENIX-3534:
---------------------------------------
One corner case we need to deal with is deletion of a column (or non inclusion
of a column) from the base table for a child view. This is a relatively common
practice, as often views want only a subset of the columns from the base table.
Here's an example of how to do that today:
{code}
CREATE TABLE T (A VARCHAR PRIMARY KEY, B VARCHAR, C VARCHAR);
CREATE VIEW V (D VARCHAR) AS SELECT * FROM T WHERE A = 'FOO';
ALTER VIEW V DROP COLUMN B;
{code}
So although we only currently allow a view to be defined with "SELECT *" which
means that you initially inherit all columns from the parent, you can remove
them after the fact. We also would like to allow a subset of the columns to be
selected in the initial view creation, so that's the other way this would
happen.
Today we copy the metadata from the table to the view and when the view is
altered, we flag it as "diverged" from the base table (by setting the
BASE_COLUMN_COUNT to a special value, -1 I believe). This is not really
correct, as if say column C is dropped from the base table, it really should be
dropped from the children as well (which is likely not the case now). For
example, try this:
{code}
ALTER TABLE T DROP COLUMN C;
SELECT C FROM V; -- this should fail
{code}
Rather than copy the metadata (which would get us into the same issue we have
today if SYSTEM.CATALOG were split), we really should be recording at the view
which columns are not included. Then when we do our combining logic, we can
exclude those particular columns. One way we could do this is to introduce a
new VARCHAR ARRAY column to SYSTEM.CATALOG (say an EXCLUDE_COLUMNS column). We
don't need any metadata other than the name, so I think an array would work
pretty well.
One corner case on this corner case is how we want to handle adding a column
back to a view that has been dropped in the past (i.e. it's in the
EXCLUDE_COLUMNS array). If the type, precision, and scale match the parent
table, then we could allow it and just remove the column from the
EXCLUDE_COLUMNS (and give an error otherwise).
WDYT, [~churromorales]?
> Support multi region SYSTEM.CATALOG table
> -----------------------------------------
>
> Key: PHOENIX-3534
> URL: https://issues.apache.org/jira/browse/PHOENIX-3534
> Project: Phoenix
> Issue Type: Bug
> Reporter: James Taylor
> Assignee: churro morales
>
> Currently Phoenix requires that the SYSTEM.CATALOG table is single region
> based on the server-side row locks being held for operations that impact a
> table and all of it's views. For example, adding/removing a column from a
> base table pushes this change to all views.
> As an alternative to making the SYSTEM.CATALOG transactional (PHOENIX-2431),
> when a new table is created we can do a lazy cleanup of any rows that may be
> left over from a failed DDL call (kudos to [~lhofhansl] for coming up with
> this idea). To implement this efficiently, we'd need to also do PHOENIX-2051
> so that we can efficiently find derived views.
> The implementation would rely on an optimistic concurrency model based on
> checking our sequence numbers for each table/view before/after updating. Each
> table/view row would be individually locked for their change (metadata for a
> view or table cannot span regions due to our split policy), with the sequence
> number being incremented under lock and then returned to the client.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
