Details

    • Type: Sub-task
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 4.5.0
    • Labels:

      Description

      We currently disallow any schema modifications to a table that has views. We should relax that constraint and push the schema change as necessary out to all views.

      1. PHOENIX-1504-wip.patch
        65 kB
        Dave Hacker
      2. PHOENIX-1504.patch
        130 kB
        Samarth Jain
      3. PHOENIX-1504_v2.patch
        133 kB
        Samarth Jain
      4. PHOENIX-1504_v3.patch
        134 kB
        Samarth Jain
      5. PHOENIX-1504_master.patch
        146 kB
        Samarth Jain
      6. PHOENIX-1504-4.x-1.0.patch
        146 kB
        Samarth Jain

        Activity

        Hide
        jamestaylor James Taylor added a comment -

        Quick summary on the proposed implementation strategy:

        • Make one-time single pass through all views and set new SYSTEM.CATALOG BASE_COLUMN_COUNT column for how many columns are from the base table. We can do this in ConnectionQueryServicesImpl.init() upon first connection to a cluster that hasn't been upgraded.
        • In MetaDataEndPointImpl, when a column is added to a base table with views, instead of failing, we'll add the same column, in the same position to any views that have the same number of columns inherited from the base table.
        • In MetaDataEndPointImpl, when a column is added to a view, take a lock out on the physical table to prevent any race conditions.
        • Prevent the removal of any of the first N columns (where N is the number of columns inherited from the base table) from a view.

        This assumes that all metadata is in a single region (as otherwise you wouldn't be able to take a lock out for the parent table when a view is updated). Longer term we'll likely make DDL operations transactional so we can relax this constraint. We could optionally add a custom split policy to prevent any splits from occurring.

        Show
        jamestaylor James Taylor added a comment - Quick summary on the proposed implementation strategy: Make one-time single pass through all views and set new SYSTEM.CATALOG BASE_COLUMN_COUNT column for how many columns are from the base table. We can do this in ConnectionQueryServicesImpl.init() upon first connection to a cluster that hasn't been upgraded. In MetaDataEndPointImpl, when a column is added to a base table with views, instead of failing, we'll add the same column, in the same position to any views that have the same number of columns inherited from the base table. In MetaDataEndPointImpl, when a column is added to a view, take a lock out on the physical table to prevent any race conditions. Prevent the removal of any of the first N columns (where N is the number of columns inherited from the base table) from a view. This assumes that all metadata is in a single region (as otherwise you wouldn't be able to take a lock out for the parent table when a view is updated). Longer term we'll likely make DDL operations transactional so we can relax this constraint. We could optionally add a custom split policy to prevent any splits from occurring.
        Hide
        dhacker1341 Dave Hacker added a comment -

        I've made some progress on this but won't be able to spend more time on it.

        I've completed enough to have add column working from 4.5 moving forward, but upgrade and error handling from earlier client/server versions is not yet complete, minus some concurrency issues that need to be addressed and tested.

        Here is what works

        • Alter table add column will appropriately update the system.catalog table for the table and all of its child views if phoenix is deployed in a new environment

        Here is what is left

        • Figure out a locking strategy that works and test it ( I recommend locking the parent table anytime a view is altered, this has to be done before taking the lock on the view, which actually eliminates the need to lock the view) The con here is it may be too coarse in the case of lots of views being altered at the same time.
        • Determine if there are any view types that should not automatically have the column added
        • Upgrade path for old versions of phoenix to version 4.5 to populate base_column_count
        • Figure out what to do in the case of base_column_count not being equals to the column count of the parent table
        • Invalidate server side cache if necessary
        • Support remove column
        Show
        dhacker1341 Dave Hacker added a comment - I've made some progress on this but won't be able to spend more time on it. I've completed enough to have add column working from 4.5 moving forward, but upgrade and error handling from earlier client/server versions is not yet complete, minus some concurrency issues that need to be addressed and tested. Here is what works Alter table add column will appropriately update the system.catalog table for the table and all of its child views if phoenix is deployed in a new environment Here is what is left Figure out a locking strategy that works and test it ( I recommend locking the parent table anytime a view is altered, this has to be done before taking the lock on the view, which actually eliminates the need to lock the view) The con here is it may be too coarse in the case of lots of views being altered at the same time. Determine if there are any view types that should not automatically have the column added Upgrade path for old versions of phoenix to version 4.5 to populate base_column_count Figure out what to do in the case of base_column_count not being equals to the column count of the parent table Invalidate server side cache if necessary Support remove column
        Hide
        samarthjain Samarth Jain added a comment -

        Dave Hacker - could you please provide me the rebased patch for 4.x-98 branch? It would make it much easier for me to take over the patch then. Thanks!

        Show
        samarthjain Samarth Jain added a comment - Dave Hacker - could you please provide me the rebased patch for 4.x-98 branch? It would make it much easier for me to take over the patch then. Thanks!
        Hide
        samarthjain Samarth Jain added a comment -

        I am not able to run tests in my local environment for some reason. Hoping pre-commit gods will be happy and pick up this patch.

        Show
        samarthjain Samarth Jain added a comment - I am not able to run tests in my local environment for some reason. Hoping pre-commit gods will be happy and pick up this patch.
        Hide
        samarthjain Samarth Jain added a comment -

        Correct patch.

        Show
        samarthjain Samarth Jain added a comment - Correct patch.
        Hide
        samarthjain Samarth Jain added a comment -

        I was finally able to run the test suite on my laptop. Attached is the patch for 4.x-98 branch.

        James Taylor - please review when you get a chance.

        Show
        samarthjain Samarth Jain added a comment - I was finally able to run the test suite on my laptop. Attached is the patch for 4.x-98 branch. James Taylor - please review when you get a chance.
        Hide
        jamestaylor James Taylor added a comment -

        Great work, Samarth Jain. Excellent tests. Couple of minor nits to fix on commit:

        • ViewIT.java looks like it has not substantive changes, so please revert.
        • Any chance that BASE_COLUMN_COUNT will be null (i.e. pre-commit of the upgrade script) here in MetaDataEndPointImpl? Maybe a check for null with a default value would be prudent here?
          +        Cell baseColumnCountKv = tableKeyValues[BASE_COLUMN_COUNT_INDEX];
          +        Integer baseColumnCount = PInteger.INSTANCE.getCodec().decodeInt(baseColumnCountKv.getValueArray(),
          +            baseColumnCountKv.getValueOffset(), SortOrder.getDefault());
          
        • Not sure if I'm seeing double here post Warriror's championship party, but seems that this is repeated?
          +        scan.addColumn(TABLE_FAMILY_BYTES, TABLE_SEQ_NUM_BYTES);
          +
          +        scan.addColumn(TABLE_FAMILY_BYTES, TABLE_SEQ_NUM_BYTES);
          
        • Rather than pass a boolean isAdd into mutateColumn(), how about removing the findChildViews logic and having it be different in the updateMutation implementation provided by dropColumn and addColumn? In dropColumn, you'd just return a MutationCode.UNALLOWED_TABLE_MUTATION if there are child views. In addColumn, you'd return that if the metadata spans multiple regions or if a view has child views.
          +                    TableViewFinderResult childViewsResult =
          +                            findChildViews(region, tenantId, table,
          +                                (type == PTableType.VIEW ? PARENT_TABLE_BYTES
          +                                        : PHYSICAL_TABLE_BYTES));
          +                    if (childViewsResult.hasViews()) {
          +                        /*
          +                         * Table mutations are not allowed if:
          +                         * 1) Metadata for child views is split over more than one region.
          +                         * 2) Dropping columns for tables or views that have child views
          +                         * 3) Adding columns for views that have child views.
          +                         * 
          +                         */
          +                        if (!childViewsResult.allViewsInSingleRegion() || !isAdd || (type == PTableType.VIEW && isAdd)) {
          +                            return new MetaDataMutationResult(
          +                                    MutationCode.UNALLOWED_TABLE_MUTATION,
          +                                    EnvironmentEdgeManager.currentTimeMillis(), null);
          +                        } else {
          +                            addRowsToChildViews(tableMetadata, schemaName, tableName,
          +                                viewMutations, invalidateList, clientTimeStamp, childViewsResult,
          +                                region, locks);
          +                        }
                               }
          
        • Any reason not to pass only List<Mutation>tableMetadata to addRowsToChildViews and just add the new metadata rows in-place (iterating only up to the the original size)?
        • Minor nit: how about just calling upgradeTo4_5_0(metaConnection) in the try and getting rid of the if statement?
          +                                
          +                                if (currentServerSideTableTimeStamp < MetaDataProtocol.MIN_SYSTEM_TABLE_TIMESTAMP_4_5_0) {
          +                                    columnsToAdd = PhoenixDatabaseMetaData.BASE_COLUMN_COUNT + " "
          +                                            + PInteger.INSTANCE.getSqlTypeName();
          +                                    boolean skipUpgrade = false;
          +                                    try {
          +                                        addColumn(metaConnection, PhoenixDatabaseMetaData.SYSTEM_CATALOG,
          +                                                MetaDataProtocol.MIN_SYSTEM_TABLE_TIMESTAMP, columnsToAdd, false);
          +                                    } catch (ColumnAlreadyExistsException ignored) {
          +                                        /* 
          +                                         * Upgrade to 4.5 is a slightly special case. We use the fact that the column
          +                                         * BASE_COLUMN_COUNT is already part of the meta-data schema as the signal that
          +                                         * the server side upgrade has finished or is in progress.
          +                                         */
          +                                        skipUpgrade = true;
          +                                    }
          +                                    if (!skipUpgrade) {
          +                                        upgradeTo4_5_0(metaConnection);
          +                                    }
          +                                }
          
        • In QueryConstants, it's best to add new columns at the end, otherwise the column ordinal positions of preceding SYSTEM.CATALOG columns will get increment (just in case folks are counting on the ordinal position).
        • Use your constant here:
          @@ -253,18 +254,18 @@ public class PTableImpl implements PTable {
                   return new PTableImpl(tenantId, schemaName, tableName, type, state, timeStamp, sequenceNumber, pkName, bucketNum, columns, dataSchemaName,
                           dataTableName, indexes, isImmutableRows, physicalNames, defaultFamilyName,
                           viewExpression, disableWAL, multiTenant, storeNulls, viewType, viewIndexId,
          -                indexType, PTableStats.EMPTY_STATS);
          +                indexType, PTableStats.EMPTY_STATS, -1);
          
        • Remove TODO here:
          +                multiTenant, storeNulls, viewType, viewIndexId, indexType, baseColumnCount); // TODO
          
        • Not a huge deal, but can the array actually be null here?
          diff --git a/phoenix-core/src/main/java/org/apache/phoenix/util/ByteUtil.java b/phoenix-core/src/main/java/org/apache/phoenix/util/ByteUtil.java
          index 1e3516d..1f4a285 100644
          --- a/phoenix-core/src/main/java/org/apache/phoenix/util/ByteUtil.java
          +++ b/phoenix-core/src/main/java/org/apache/phoenix/util/ByteUtil.java
          @@ -253,13 +253,17 @@ public class ByteUtil {
               public static byte[] concat(byte[] first, byte[]... rest) {
                   int totalLength = first.length;
                   for (byte[] array : rest) {
          -            totalLength += array.length;
          +            if (array != null) {
          +                totalLength += array.length;
          +            }
          
        Show
        jamestaylor James Taylor added a comment - Great work, Samarth Jain . Excellent tests. Couple of minor nits to fix on commit: ViewIT.java looks like it has not substantive changes, so please revert. Any chance that BASE_COLUMN_COUNT will be null (i.e. pre-commit of the upgrade script) here in MetaDataEndPointImpl? Maybe a check for null with a default value would be prudent here? + Cell baseColumnCountKv = tableKeyValues[BASE_COLUMN_COUNT_INDEX]; + Integer baseColumnCount = PInteger.INSTANCE.getCodec().decodeInt(baseColumnCountKv.getValueArray(), + baseColumnCountKv.getValueOffset(), SortOrder.getDefault()); Not sure if I'm seeing double here post Warriror's championship party, but seems that this is repeated? + scan.addColumn(TABLE_FAMILY_BYTES, TABLE_SEQ_NUM_BYTES); + + scan.addColumn(TABLE_FAMILY_BYTES, TABLE_SEQ_NUM_BYTES); Rather than pass a boolean isAdd into mutateColumn(), how about removing the findChildViews logic and having it be different in the updateMutation implementation provided by dropColumn and addColumn? In dropColumn, you'd just return a MutationCode.UNALLOWED_TABLE_MUTATION if there are child views. In addColumn, you'd return that if the metadata spans multiple regions or if a view has child views. + TableViewFinderResult childViewsResult = + findChildViews(region, tenantId, table, + (type == PTableType.VIEW ? PARENT_TABLE_BYTES + : PHYSICAL_TABLE_BYTES)); + if (childViewsResult.hasViews()) { + /* + * Table mutations are not allowed if : + * 1) Metadata for child views is split over more than one region. + * 2) Dropping columns for tables or views that have child views + * 3) Adding columns for views that have child views. + * + */ + if (!childViewsResult.allViewsInSingleRegion() || !isAdd || (type == PTableType.VIEW && isAdd)) { + return new MetaDataMutationResult( + MutationCode.UNALLOWED_TABLE_MUTATION, + EnvironmentEdgeManager.currentTimeMillis(), null ); + } else { + addRowsToChildViews(tableMetadata, schemaName, tableName, + viewMutations, invalidateList, clientTimeStamp, childViewsResult, + region, locks); + } } Any reason not to pass only List<Mutation>tableMetadata to addRowsToChildViews and just add the new metadata rows in-place (iterating only up to the the original size)? Minor nit: how about just calling upgradeTo4_5_0(metaConnection) in the try and getting rid of the if statement? + + if (currentServerSideTableTimeStamp < MetaDataProtocol.MIN_SYSTEM_TABLE_TIMESTAMP_4_5_0) { + columnsToAdd = PhoenixDatabaseMetaData.BASE_COLUMN_COUNT + " " + + PInteger.INSTANCE.getSqlTypeName(); + boolean skipUpgrade = false ; + try { + addColumn(metaConnection, PhoenixDatabaseMetaData.SYSTEM_CATALOG, + MetaDataProtocol.MIN_SYSTEM_TABLE_TIMESTAMP, columnsToAdd, false ); + } catch (ColumnAlreadyExistsException ignored) { + /* + * Upgrade to 4.5 is a slightly special case . We use the fact that the column + * BASE_COLUMN_COUNT is already part of the meta-data schema as the signal that + * the server side upgrade has finished or is in progress. + */ + skipUpgrade = true ; + } + if (!skipUpgrade) { + upgradeTo4_5_0(metaConnection); + } + } In QueryConstants, it's best to add new columns at the end, otherwise the column ordinal positions of preceding SYSTEM.CATALOG columns will get increment (just in case folks are counting on the ordinal position). Use your constant here: @@ -253,18 +254,18 @@ public class PTableImpl implements PTable { return new PTableImpl(tenantId, schemaName, tableName, type, state, timeStamp, sequenceNumber, pkName, bucketNum, columns, dataSchemaName, dataTableName, indexes, isImmutableRows, physicalNames, defaultFamilyName, viewExpression, disableWAL, multiTenant, storeNulls, viewType, viewIndexId, - indexType, PTableStats.EMPTY_STATS); + indexType, PTableStats.EMPTY_STATS, -1); Remove TODO here: + multiTenant, storeNulls, viewType, viewIndexId, indexType, baseColumnCount); // TODO Not a huge deal, but can the array actually be null here? diff --git a/phoenix-core/src/main/java/org/apache/phoenix/util/ByteUtil.java b/phoenix-core/src/main/java/org/apache/phoenix/util/ByteUtil.java index 1e3516d..1f4a285 100644 --- a/phoenix-core/src/main/java/org/apache/phoenix/util/ByteUtil.java +++ b/phoenix-core/src/main/java/org/apache/phoenix/util/ByteUtil.java @@ -253,13 +253,17 @@ public class ByteUtil { public static byte [] concat( byte [] first, byte []... rest ) { int totalLength = first.length; for ( byte [] array : rest ) { - totalLength += array.length; + if (array != null ) { + totalLength += array.length; + }
        Hide
        samarthjain Samarth Jain added a comment -

        Thanks for the review James Taylor.

        Regarding the change in ByteUtil.java

        diff --git a/phoenix-core/src/main/java/org/apache/phoenix/util/ByteUtil.java b/phoenix-core/src/main/java/org/apache/phoenix/util/ByteUtil.java
        index 1e3516d..1f4a285 100644
        --- a/phoenix-core/src/main/java/org/apache/phoenix/util/ByteUtil.java
        +++ b/phoenix-core/src/main/java/org/apache/phoenix/util/ByteUtil.java
        @@ -253,13 +253,17 @@ public class ByteUtil {
             public static byte[] concat(byte[] first, byte[]... rest) {
                 int totalLength = first.length;
                 for (byte[] array : rest) {
        -            totalLength += array.length;
        +            if (array != null) {
        +                totalLength += array.length;
        +            }
        

        I noticed that the a test in TenantSpecificTablesDDLIT was failing because of an NPE in MetadataEndpointImpl. The NPE was happening because the column family of the column being added is null.
        Test code line:

         conn.createStatement().execute("alter table " + PARENT_TABLE_NAME + " add new_pk varchar primary key");
         

        NPE

        Caused by: java.lang.NullPointerException
        	at org.apache.phoenix.util.ByteUtil.concat(ByteUtil.java:256)
        	at org.apache.phoenix.coprocessor.MetaDataEndpointImpl.addRowsToChildViews(MetaDataEndpointImpl.java:1602)
        	at org.apache.phoenix.coprocessor.MetaDataEndpointImpl.access$3(MetaDataEndpointImpl.java:1571)
        	at org.apache.phoenix.coprocessor.MetaDataEndpointImpl$2.updateMutation(MetaDataEndpointImpl.java:1678)
        	at org.apache.phoenix.coprocessor.MetaDataEndpointImpl.mutateColumn(MetaDataEndpointImpl.java:1546)
        	... 11 more
        

        Line at which NPE is thrown because the column family is null.

        byte[] k = ByteUtil.concat(viewKey, QueryConstants.SEPARATOR_BYTE_ARRAY, rkmd[COLUMN_NAME_INDEX],
                                    QueryConstants.SEPARATOR_BYTE_ARRAY, rkmd[FAMILY_NAME_INDEX]);
        

        What do you think? Should we allow adding PK columns to base tables that have views? If yes, I will also add a test to make sure that the new column shows up as PK for the entire view hierarchy too.

        Show
        samarthjain Samarth Jain added a comment - Thanks for the review James Taylor . Regarding the change in ByteUtil.java diff --git a/phoenix-core/src/main/java/org/apache/phoenix/util/ByteUtil.java b/phoenix-core/src/main/java/org/apache/phoenix/util/ByteUtil.java index 1e3516d..1f4a285 100644 --- a/phoenix-core/src/main/java/org/apache/phoenix/util/ByteUtil.java +++ b/phoenix-core/src/main/java/org/apache/phoenix/util/ByteUtil.java @@ -253,13 +253,17 @@ public class ByteUtil { public static byte [] concat( byte [] first, byte []... rest ) { int totalLength = first.length; for ( byte [] array : rest ) { - totalLength += array.length; + if (array != null ) { + totalLength += array.length; + } I noticed that the a test in TenantSpecificTablesDDLIT was failing because of an NPE in MetadataEndpointImpl. The NPE was happening because the column family of the column being added is null. Test code line: conn.createStatement().execute( "alter table " + PARENT_TABLE_NAME + " add new_pk varchar primary key" ); NPE Caused by: java.lang.NullPointerException at org.apache.phoenix.util.ByteUtil.concat(ByteUtil.java:256) at org.apache.phoenix.coprocessor.MetaDataEndpointImpl.addRowsToChildViews(MetaDataEndpointImpl.java:1602) at org.apache.phoenix.coprocessor.MetaDataEndpointImpl.access$3(MetaDataEndpointImpl.java:1571) at org.apache.phoenix.coprocessor.MetaDataEndpointImpl$2.updateMutation(MetaDataEndpointImpl.java:1678) at org.apache.phoenix.coprocessor.MetaDataEndpointImpl.mutateColumn(MetaDataEndpointImpl.java:1546) ... 11 more Line at which NPE is thrown because the column family is null. byte [] k = ByteUtil.concat(viewKey, QueryConstants.SEPARATOR_BYTE_ARRAY, rkmd[COLUMN_NAME_INDEX], QueryConstants.SEPARATOR_BYTE_ARRAY, rkmd[FAMILY_NAME_INDEX]); What do you think? Should we allow adding PK columns to base tables that have views? If yes, I will also add a test to make sure that the new column shows up as PK for the entire view hierarchy too.
        Hide
        samarthjain Samarth Jain added a comment -

        Updated patch.
        I added a test AlterTableIT#testChangingPKOfBaseTableChangesPKForAllViews that verifies that adding a PK column to the base table ends up propagating as a PK column for the child views too.

        Any reason not to pass only List<Mutation>tableMetadata to addRowsToChildViews and just add the new metadata rows in-place (iterating only up to the the original size)?

        I am not sure I understood this particular comment James Taylor. All the other params are needed for addRowsToChildViews.

        Show
        samarthjain Samarth Jain added a comment - Updated patch. I added a test AlterTableIT#testChangingPKOfBaseTableChangesPKForAllViews that verifies that adding a PK column to the base table ends up propagating as a PK column for the child views too. Any reason not to pass only List<Mutation>tableMetadata to addRowsToChildViews and just add the new metadata rows in-place (iterating only up to the the original size)? I am not sure I understood this particular comment James Taylor . All the other params are needed for addRowsToChildViews.
        Hide
        jamestaylor James Taylor added a comment -

        +1 to allowing nullable PK columns to be added to the base table.

        The comment to to pass only List<Mutation>tableMetadata wasn't specific enough (and not super important either). I meant only pass tableMetadata instead of both tableMetaData and viewMetadata as in the end you're just combining them together. However, upon thinking about this more, it may be better to do this:

        • initialize viewMetadata to Collection.emptyList() outside the if statement for the "adding a column to a base table".
        • inside of that if statement (as you now know you'll be adding columns to all the views), size the list based on some rough estimate (maybe a multiple of the tableMetadata list, where the multiple is a guess at how many views there will be)?
          At least that'll prevent what might end up being a pretty sizable list from being copied again and again as it grows.
        Show
        jamestaylor James Taylor added a comment - +1 to allowing nullable PK columns to be added to the base table. The comment to to pass only List<Mutation>tableMetadata wasn't specific enough (and not super important either). I meant only pass tableMetadata instead of both tableMetaData and viewMetadata as in the end you're just combining them together. However, upon thinking about this more, it may be better to do this: initialize viewMetadata to Collection.emptyList() outside the if statement for the "adding a column to a base table". inside of that if statement (as you now know you'll be adding columns to all the views), size the list based on some rough estimate (maybe a multiple of the tableMetadata list, where the multiple is a guess at how many views there will be)? At least that'll prevent what might end up being a pretty sizable list from being copied again and again as it grows.
        Hide
        samarthjain Samarth Jain added a comment -

        Updated patch.

        Show
        samarthjain Samarth Jain added a comment - Updated patch.
        Hide
        jamestaylor James Taylor added a comment -

        +1. Looks great, Samarth Jain.

        Show
        jamestaylor James Taylor added a comment - +1. Looks great, Samarth Jain .
        Hide
        samarthjain Samarth Jain added a comment -

        Thanks for the reviews James Taylor. Below is the list of patches that I have pushed to various branches:

        PHOENIX-1504_v3.patch -> 4.x-HBase-0.98
        PHOENIX-1504_master.patch -> master branch
        PHOENIX-1504-4.x-1.0.patch -> 4.x-HBase-1.0

        The patches are different because of Region/HRegion/RegionCoProcessor environment changes in 0.98, 1.1 and 1.0 versions of HBase.

        Show
        samarthjain Samarth Jain added a comment - Thanks for the reviews James Taylor . Below is the list of patches that I have pushed to various branches: PHOENIX-1504 _v3.patch -> 4.x-HBase-0.98 PHOENIX-1504 _master.patch -> master branch PHOENIX-1504 -4.x-1.0.patch -> 4.x-HBase-1.0 The patches are different because of Region/HRegion/RegionCoProcessor environment changes in 0.98, 1.1 and 1.0 versions of HBase.
        Hide
        hudson Hudson added a comment -

        SUCCESS: Integrated in Phoenix-master #790 (See https://builds.apache.org/job/Phoenix-master/790/)
        PHOENIX-1504 Support adding column to a table that has views (Samarth Jain/Dave Hacker) (samarth.jain: rev e78eb6faceec40d8b09fbc7dde778b87fe54feef)

        • phoenix-core/src/it/java/org/apache/phoenix/end2end/TenantSpecificTablesDDLIT.java
        • phoenix-core/src/it/java/org/apache/phoenix/end2end/AlterTableIT.java
        • phoenix-core/src/main/java/org/apache/phoenix/schema/MetaDataClient.java
        • phoenix-core/src/main/java/org/apache/phoenix/schema/PTable.java
        • phoenix-core/src/main/java/org/apache/phoenix/query/QueryConstants.java
        • phoenix-core/src/it/java/org/apache/phoenix/end2end/UpgradeIT.java
        • phoenix-core/src/main/java/org/apache/phoenix/schema/DelegateTable.java
        • phoenix-core/src/main/java/org/apache/phoenix/util/UpgradeUtil.java
        • phoenix-core/src/main/java/org/apache/phoenix/schema/PTableImpl.java
        • phoenix-core/src/main/java/org/apache/phoenix/jdbc/PhoenixDatabaseMetaData.java
        • phoenix-core/src/main/java/org/apache/phoenix/query/ConnectionQueryServicesImpl.java
        • phoenix-core/src/main/java/org/apache/phoenix/coprocessor/MetaDataProtocol.java
        • phoenix-core/src/main/java/org/apache/phoenix/util/ByteUtil.java
        • phoenix-core/src/main/java/org/apache/phoenix/coprocessor/MetaDataEndpointImpl.java
        • phoenix-core/src/main/java/org/apache/phoenix/coprocessor/generated/PTableProtos.java
        Show
        hudson Hudson added a comment - SUCCESS: Integrated in Phoenix-master #790 (See https://builds.apache.org/job/Phoenix-master/790/ ) PHOENIX-1504 Support adding column to a table that has views (Samarth Jain/Dave Hacker) (samarth.jain: rev e78eb6faceec40d8b09fbc7dde778b87fe54feef) phoenix-core/src/it/java/org/apache/phoenix/end2end/TenantSpecificTablesDDLIT.java phoenix-core/src/it/java/org/apache/phoenix/end2end/AlterTableIT.java phoenix-core/src/main/java/org/apache/phoenix/schema/MetaDataClient.java phoenix-core/src/main/java/org/apache/phoenix/schema/PTable.java phoenix-core/src/main/java/org/apache/phoenix/query/QueryConstants.java phoenix-core/src/it/java/org/apache/phoenix/end2end/UpgradeIT.java phoenix-core/src/main/java/org/apache/phoenix/schema/DelegateTable.java phoenix-core/src/main/java/org/apache/phoenix/util/UpgradeUtil.java phoenix-core/src/main/java/org/apache/phoenix/schema/PTableImpl.java phoenix-core/src/main/java/org/apache/phoenix/jdbc/PhoenixDatabaseMetaData.java phoenix-core/src/main/java/org/apache/phoenix/query/ConnectionQueryServicesImpl.java phoenix-core/src/main/java/org/apache/phoenix/coprocessor/MetaDataProtocol.java phoenix-core/src/main/java/org/apache/phoenix/util/ByteUtil.java phoenix-core/src/main/java/org/apache/phoenix/coprocessor/MetaDataEndpointImpl.java phoenix-core/src/main/java/org/apache/phoenix/coprocessor/generated/PTableProtos.java
        Hide
        lukaslalinsky Lukas Lalinsky added a comment -

        I don't know if it's a more general problem, but at least for me the queryserver won't start after this change, see PHOENIX-2066

        Show
        lukaslalinsky Lukas Lalinsky added a comment - I don't know if it's a more general problem, but at least for me the queryserver won't start after this change, see PHOENIX-2066
        Hide
        enis Enis Soztutar added a comment -

        Bulk close of all issues that has been resolved in a released version.

        Show
        enis Enis Soztutar added a comment - Bulk close of all issues that has been resolved in a released version.

          People

          • Assignee:
            samarthjain Samarth Jain
            Reporter:
            jamestaylor James Taylor
          • Votes:
            4 Vote for this issue
            Watchers:
            8 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development