[
https://issues.apache.org/jira/browse/PHOENIX-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16462940#comment-16462940
]
Thomas D'Silva commented on PHOENIX-3534:
-----------------------------------------
[~jamestaylor]
Currently if you change a table property on a base table that is valid on a
view we propagate it to all child views. If the table property is not mutable
on the child view we set it to the parent view value. If it is mutable and the
view didn't change the property we set it to the parent view value.
After splittable system catalog since we resolve the parent hierarchy of a view
while combining columns we can also inherit the table properties from the base
table. If a table property is valid on a view but not mutable on a view we can
just use the base table value. If it is mutable on a view, we don't know if the
property was changed on the view on not, so we have to use the value that is
set on the view.
This is different from the existing behavior, where if you change a table
property that is valid on a view and mutable on view and if it wasn't changed
on the view, it would get propagated to all the child views. Is this ok?
> 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: Thomas D'Silva
> Priority: Major
> Attachments: PHOENIX-3534-wip.patch
>
>
> 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
(v7.6.3#76005)
