[ 
https://issues.apache.org/jira/browse/PHOENIX-6191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17232202#comment-17232202
 ] 

ASF GitHub Bot commented on PHOENIX-6191:
-----------------------------------------

virajjasani commented on pull request #966:
URL: https://github.com/apache/phoenix/pull/966#issuecomment-727523677


   Also, test `ViewMetadataIT.testViewAndTableAndDropCascade()` failure seem 
flaky and not permanent, but still good to confirm. Agree with @yanxinyi , let 
me spin a new build for better visibility.
   Thanks


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
[email protected]


> Creating a view which has its own new columns should also do checkAndPut 
> checks on SYSTEM.MUTEX
> -----------------------------------------------------------------------------------------------
>
>                 Key: PHOENIX-6191
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-6191
>             Project: Phoenix
>          Issue Type: Bug
>    Affects Versions: 5.0.0, 4.15.0
>            Reporter: Chinmay Kulkarni
>            Assignee: Chinmay Kulkarni
>            Priority: Critical
>             Fix For: 5.1.0, 4.16.0
>
>
> Currently, when creating a view we do conditional writes with a checkAndPut 
> to SYSTEM.MUTEX for the keys:
> (<physical parent's schema name>, <physical parent's table name>, <column 
> name>)
> for each column in the view WHERE clause. Similarly, when issuing an ALTER 
> TABLE/VIEW, we do a conditional write with a checkAndPut to SYSTEM.MUTEX for 
> the key:
> (<physical parent's schema name>, <physical parent's table name>, <name of 
> the column to add/drop>)
> to prevent conflicting modifications between a base table/view and its child 
> views. However, if we create a view with its own new columns, for ex:
> {code:sql}
> CREATE VIEW V1 (NEW_COL1 INTEGER, NEW_COL2 INTEGER) AS SELECT * FROM T1 WHERE 
> B = 10;
> {code}
> we will not do a checkAndPut with the new columns being added to the view 
> (NEW_COL1 and NEW_COL2) thus conflicting concurrent mutations may occur to a 
> parent in this case, for ex: a simultaneous ALTER TABLE/VIEW of the parent 
> which adds NEW_COL1 as a VARCHAR. This will lead to data being unable to be 
> read properly.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to