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

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

Github user twdsilva commented on a diff in the pull request:

    https://github.com/apache/phoenix/pull/303#discussion_r192460500
  
    --- Diff: phoenix-core/src/it/java/org/apache/phoenix/end2end/ViewIT.java 
---
    @@ -388,51 +435,65 @@ public void 
testViewAndTableInDifferentSchemas(boolean isNamespaceMapped) throws
             } catch (TableNotFoundException ignore) {
             }
             ddl = "DROP TABLE " + fullTableName1;
    -        validateCannotDropTableWithChildViewsWithoutCascade(conn, 
fullTableName1);
             ddl = "DROP VIEW " + fullViewName2;
             conn.createStatement().execute(ddl);
             ddl = "DROP TABLE " + fullTableName1;
             conn.createStatement().execute(ddl);
         }
     
    -    
    +
         @Test
    -    public void testDisallowDropOfColumnOnParentTable() throws Exception {
    +    public void testDropOfColumnOnParentTableInvalidatesView() throws 
Exception {
             Connection conn = DriverManager.getConnection(getUrl());
    +        String fullTableName = generateUniqueTableName();
    +        String viewName = generateUniqueViewName();
    +        splitSystemCatalog(Lists.newArrayList(fullTableName, viewName));
    +
             String ddl = "CREATE TABLE " + fullTableName + " (k1 INTEGER NOT 
NULL, k2 INTEGER NOT NULL, v1 DECIMAL, CONSTRAINT pk PRIMARY KEY (k1, k2))" + 
tableDDLOptions;
             conn.createStatement().execute(ddl);
    -        String viewName = "V_" + generateUniqueName();
             ddl = "CREATE VIEW " + viewName + "(v2 VARCHAR, v3 VARCHAR) AS 
SELECT * FROM " + fullTableName + " WHERE v1 = 1.0";
             conn.createStatement().execute(ddl);
             
    -        try {
    -            conn.createStatement().execute("ALTER TABLE " + fullTableName 
+ " DROP COLUMN v1");
    -            fail();
    -        } catch (SQLException e) {
    -            
assertEquals(SQLExceptionCode.CANNOT_MUTATE_TABLE.getErrorCode(), 
e.getErrorCode());
    +        conn.createStatement().execute("ALTER TABLE " + fullTableName + " 
DROP COLUMN v1");
    +        // TODO see if its possibel to prevent the dropping of a column 
thats required by a child view (for its view where clause)
    +        // the view should be invalid
    --- End diff --
    
    @JamesRTaylor 
    
    I think we can avoid this while dropping a column. However while adding a 
column as the view and base table could be on different region servers we need 
to detect and prevent a conflicting add column change happening at the same 
time. I couldn't think of a better way to prevent this other than doing a 
checkAndPut. 
    If we do the checkAndPut in MetadataClient to ensure that only one client 
is able to add the same column at the same time and then make the rpc to the 
server to add the column, do you think think that would scale?


> 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)

Reply via email to