[
https://issues.apache.org/jira/browse/PHOENIX-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15963585#comment-15963585
]
churro morales commented on PHOENIX-3534:
-----------------------------------------
Discussed with [~jamestaylor] today. Right now we can only update per
(table/view) so we know nothing about relations for add / drop columns or
create view.
So the logic can be the following:
For all reads we do this:
As we walk up the tree, we create a list of PColumns. If the column is
contained in the parent as well, we see which one is older and keep that one
(we take the min timestamp). For dropped columns as described above, we decide
whether to drop the column based on the timestamp again but this time the
decision is made based on the max timestamp. If the dropped column timestamp
is newer than the columns timestamp, we exclude it, if it is older than the
column timestamp we include it in the result.
> 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)
