[jira] [Updated] (PHOENIX-4298) refactoring to avoid using deprecated API for Put/Delete
[ https://issues.apache.org/jira/browse/PHOENIX-4298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ankit Singhal updated PHOENIX-4298: --- Fix Version/s: (was: 4.13.0) 5.0.0 > refactoring to avoid using deprecated API for Put/Delete > > > Key: PHOENIX-4298 > URL: https://issues.apache.org/jira/browse/PHOENIX-4298 > Project: Phoenix > Issue Type: Sub-task >Reporter: Sergey Soldatov >Assignee: Sergey Soldatov > Labels: HBase-2.0 > Fix For: 5.0.0 > > Attachments: PHOENIX-4298.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PHOENIX-4298) refactoring to avoid using deprecated API for Put/Delete
[ https://issues.apache.org/jira/browse/PHOENIX-4298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16221833#comment-16221833 ] Ankit Singhal commented on PHOENIX-4298: +1, Thanks [~sergey.soldatov]. Committed to branch 5.0-HBase-2.0. > refactoring to avoid using deprecated API for Put/Delete > > > Key: PHOENIX-4298 > URL: https://issues.apache.org/jira/browse/PHOENIX-4298 > Project: Phoenix > Issue Type: Sub-task >Reporter: Sergey Soldatov >Assignee: Sergey Soldatov > Labels: HBase-2.0 > Fix For: 5.0.0 > > Attachments: PHOENIX-4298.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (PHOENIX-4289) UPDATE STATISTICS command does not collect stats for local indexes
[
https://issues.apache.org/jira/browse/PHOENIX-4289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Samarth Jain updated PHOENIX-4289:
--
Attachment: PHOENIX-4289.patch
[~jamestaylor], please review.
> UPDATE STATISTICS command does not collect stats for local indexes
> --
>
> Key: PHOENIX-4289
> URL: https://issues.apache.org/jira/browse/PHOENIX-4289
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.12.0
> Environment: HBase 1.3.1, Phoenix 4.12.0
>Reporter: Mujtaba Chohan
>Assignee: Samarth Jain
> Labels: localIndex
> Attachments: PHOENIX-4289.patch
>
>
> With clean {{SYSTEM.STATS}} table and restarted HBase server+Phoenix client.
> Ran {{UPDATE STATISTICS T ALL}} command. Global guidepost width is set to
> 100M. No stats are generated for any of the local indexes on table T.
> {noformat}
> explain select count(*) from T;
> +---+-++--+
> | PLAN|
> EST_BYTES_READ | EST_ROWS_READ | EST_INFO_TS |
> +---+-++--+
> | CLIENT 8-CHUNK PARALLEL 8-WAY RANGE SCAN OVER T [1] |
> null| null | null |
> | SERVER FILTER BY FIRST KEY ONLY |
> null| null | null |
> | SERVER AGGREGATE INTO SINGLE ROW |
> null| null | null |
> +---+-++--+
> select * from system.stats;
> +--++-++--++
> |PHYSICAL_NAME | COLUMN_FAMILY | GUIDE_POST_KEY |
> GUIDE_POSTS_WIDTH | LAST_STATS_UPDATE_TIME | GUIDE_POSTS_ROW_COUNT |
> +--++-++--++
> | T || | null |
> 2017-10-16 18:36:57.884 | null |
> | T | 0 | [B@9bd0fa6 | 10099 |
>| 75756 |
> | T | 0 | [B@59d2103b | 10057 |
>| 75748 |
> | T | 0 | [B@39dcf4b0 | 10058 |
>| 75748 |
> | T | 0 | [B@6e4de19b | 10081 |
>| 75743 |
> | T | 0 | [B@f6c03cb | 10044 |
>| 75744 |
> | T | 0 | [B@46f699d5 | 10023 |
>| 75741 |
> | T | 0 | [B@18518ccf | 10019 |
>| 75749 |
> | T | 0 | [B@1991f767 | 10097 |
>| 75740 |
> | T | 0 | [B@768ccdc5 | 10092 |
>| 75740 |
> | T | 0 | [B@4c6daf0 | 10026 |
>| 75739 |
> | T | 0 | [B@10650953 | 10054 |
>| 75731 |
> | T | 0 | [B@659eef7 | 10092 |
>| 75741 |
> | T | 0 | [B@162be91c | 10023 |
>| 75752 |
> | T | 0 | [B@2488b073 | 10096 |
>| 75743 |
> | T | 0 | [B@1c9f0a20 | 10025 |
>| 75745 |
> | T | 0 | [B@55787112 | 10104 |
>| 75725 |
> | T | 0 | [B@1cd201a8 | 10019 |
>| 75748 |
> | T | 0 | [B@7db82169 | 10080 |
>| 75740 |
> | T | 0 | [B@1992eaf4 | 10079 |
>| 75733 |
> | T | 0
[jira] [Updated] (PHOENIX-4289) UPDATE STATISTICS command does not collect stats for local indexes
[
https://issues.apache.org/jira/browse/PHOENIX-4289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Samarth Jain updated PHOENIX-4289:
--
Attachment: (was: PHOENIX-4289.patch)
> UPDATE STATISTICS command does not collect stats for local indexes
> --
>
> Key: PHOENIX-4289
> URL: https://issues.apache.org/jira/browse/PHOENIX-4289
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.12.0
> Environment: HBase 1.3.1, Phoenix 4.12.0
>Reporter: Mujtaba Chohan
>Assignee: Samarth Jain
> Labels: localIndex
> Attachments: PHOENIX-4289.patch
>
>
> With clean {{SYSTEM.STATS}} table and restarted HBase server+Phoenix client.
> Ran {{UPDATE STATISTICS T ALL}} command. Global guidepost width is set to
> 100M. No stats are generated for any of the local indexes on table T.
> {noformat}
> explain select count(*) from T;
> +---+-++--+
> | PLAN|
> EST_BYTES_READ | EST_ROWS_READ | EST_INFO_TS |
> +---+-++--+
> | CLIENT 8-CHUNK PARALLEL 8-WAY RANGE SCAN OVER T [1] |
> null| null | null |
> | SERVER FILTER BY FIRST KEY ONLY |
> null| null | null |
> | SERVER AGGREGATE INTO SINGLE ROW |
> null| null | null |
> +---+-++--+
> select * from system.stats;
> +--++-++--++
> |PHYSICAL_NAME | COLUMN_FAMILY | GUIDE_POST_KEY |
> GUIDE_POSTS_WIDTH | LAST_STATS_UPDATE_TIME | GUIDE_POSTS_ROW_COUNT |
> +--++-++--++
> | T || | null |
> 2017-10-16 18:36:57.884 | null |
> | T | 0 | [B@9bd0fa6 | 10099 |
>| 75756 |
> | T | 0 | [B@59d2103b | 10057 |
>| 75748 |
> | T | 0 | [B@39dcf4b0 | 10058 |
>| 75748 |
> | T | 0 | [B@6e4de19b | 10081 |
>| 75743 |
> | T | 0 | [B@f6c03cb | 10044 |
>| 75744 |
> | T | 0 | [B@46f699d5 | 10023 |
>| 75741 |
> | T | 0 | [B@18518ccf | 10019 |
>| 75749 |
> | T | 0 | [B@1991f767 | 10097 |
>| 75740 |
> | T | 0 | [B@768ccdc5 | 10092 |
>| 75740 |
> | T | 0 | [B@4c6daf0 | 10026 |
>| 75739 |
> | T | 0 | [B@10650953 | 10054 |
>| 75731 |
> | T | 0 | [B@659eef7 | 10092 |
>| 75741 |
> | T | 0 | [B@162be91c | 10023 |
>| 75752 |
> | T | 0 | [B@2488b073 | 10096 |
>| 75743 |
> | T | 0 | [B@1c9f0a20 | 10025 |
>| 75745 |
> | T | 0 | [B@55787112 | 10104 |
>| 75725 |
> | T | 0 | [B@1cd201a8 | 10019 |
>| 75748 |
> | T | 0 | [B@7db82169 | 10080 |
>| 75740 |
> | T | 0 | [B@1992eaf4 | 10079 |
>| 75733 |
> | T | 0 | [B@f74e835 |
[jira] [Updated] (PHOENIX-4289) UPDATE STATISTICS command does not collect stats for local indexes
[
https://issues.apache.org/jira/browse/PHOENIX-4289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Samarth Jain updated PHOENIX-4289:
--
Attachment: PHOENIX-4289.patch
> UPDATE STATISTICS command does not collect stats for local indexes
> --
>
> Key: PHOENIX-4289
> URL: https://issues.apache.org/jira/browse/PHOENIX-4289
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.12.0
> Environment: HBase 1.3.1, Phoenix 4.12.0
>Reporter: Mujtaba Chohan
>Assignee: Samarth Jain
> Labels: localIndex
> Attachments: PHOENIX-4289.patch
>
>
> With clean {{SYSTEM.STATS}} table and restarted HBase server+Phoenix client.
> Ran {{UPDATE STATISTICS T ALL}} command. Global guidepost width is set to
> 100M. No stats are generated for any of the local indexes on table T.
> {noformat}
> explain select count(*) from T;
> +---+-++--+
> | PLAN|
> EST_BYTES_READ | EST_ROWS_READ | EST_INFO_TS |
> +---+-++--+
> | CLIENT 8-CHUNK PARALLEL 8-WAY RANGE SCAN OVER T [1] |
> null| null | null |
> | SERVER FILTER BY FIRST KEY ONLY |
> null| null | null |
> | SERVER AGGREGATE INTO SINGLE ROW |
> null| null | null |
> +---+-++--+
> select * from system.stats;
> +--++-++--++
> |PHYSICAL_NAME | COLUMN_FAMILY | GUIDE_POST_KEY |
> GUIDE_POSTS_WIDTH | LAST_STATS_UPDATE_TIME | GUIDE_POSTS_ROW_COUNT |
> +--++-++--++
> | T || | null |
> 2017-10-16 18:36:57.884 | null |
> | T | 0 | [B@9bd0fa6 | 10099 |
>| 75756 |
> | T | 0 | [B@59d2103b | 10057 |
>| 75748 |
> | T | 0 | [B@39dcf4b0 | 10058 |
>| 75748 |
> | T | 0 | [B@6e4de19b | 10081 |
>| 75743 |
> | T | 0 | [B@f6c03cb | 10044 |
>| 75744 |
> | T | 0 | [B@46f699d5 | 10023 |
>| 75741 |
> | T | 0 | [B@18518ccf | 10019 |
>| 75749 |
> | T | 0 | [B@1991f767 | 10097 |
>| 75740 |
> | T | 0 | [B@768ccdc5 | 10092 |
>| 75740 |
> | T | 0 | [B@4c6daf0 | 10026 |
>| 75739 |
> | T | 0 | [B@10650953 | 10054 |
>| 75731 |
> | T | 0 | [B@659eef7 | 10092 |
>| 75741 |
> | T | 0 | [B@162be91c | 10023 |
>| 75752 |
> | T | 0 | [B@2488b073 | 10096 |
>| 75743 |
> | T | 0 | [B@1c9f0a20 | 10025 |
>| 75745 |
> | T | 0 | [B@55787112 | 10104 |
>| 75725 |
> | T | 0 | [B@1cd201a8 | 10019 |
>| 75748 |
> | T | 0 | [B@7db82169 | 10080 |
>| 75740 |
> | T | 0 | [B@1992eaf4 | 10079 |
>| 75733 |
> | T | 0 | [B@f74e835 | 10003
[jira] [Created] (PHOENIX-4327) Create branch 5.0-HBase-2.0 and update hbase.version to 2.0.0-alpha4-SNAPSHOT
Ankit Singhal created PHOENIX-4327:
--
Summary: Create branch 5.0-HBase-2.0 and update hbase.version to
2.0.0-alpha4-SNAPSHOT
Key: PHOENIX-4327
URL: https://issues.apache.org/jira/browse/PHOENIX-4327
Project: Phoenix
Issue Type: Sub-task
Reporter: Ankit Singhal
Assignee: Ankit Singhal
Fix For: 5.0.0
As 2.0.0-alpha4-SNAPSHOT is not available on a public repository. so the user
needs to download HBase code and install the libraries in local repository by
using maven in order to compile Phoenix code
{code}
git clone https://github.com/apache/hbase.git
git checkout branch-2
mvn clean install -DskipTests
{code}
We will update the HBase version to 2.0.0-alpha4 once it is released.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (PHOENIX-4326) Create branch 5.0-HBase-2.0 and update hbase.version to 2.0.0-alpha4-SNAPSHOT
Ankit Singhal created PHOENIX-4326:
--
Summary: Create branch 5.0-HBase-2.0 and update hbase.version to
2.0.0-alpha4-SNAPSHOT
Key: PHOENIX-4326
URL: https://issues.apache.org/jira/browse/PHOENIX-4326
Project: Phoenix
Issue Type: Sub-task
Reporter: Ankit Singhal
Assignee: Ankit Singhal
Fix For: 5.0.0
As 2.0.0-alpha4-SNAPSHOT is not available on a public repository. so the user
needs to download HBase code and install the libraries in local repository by
using maven in order to compile Phoenix code
{code}
git clone https://github.com/apache/hbase.git
git checkout branch-2
mvn clean install -DskipTests
{code}
We will update the HBase version to 2.0.0-alpha4 once it is released.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (PHOENIX-4326) Create branch 5.0-HBase-2.0 and update hbase.version to 2.0.0-alpha4-SNAPSHOT
[
https://issues.apache.org/jira/browse/PHOENIX-4326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ankit Singhal resolved PHOENIX-4326.
Resolution: Fixed
> Create branch 5.0-HBase-2.0 and update hbase.version to 2.0.0-alpha4-SNAPSHOT
> -
>
> Key: PHOENIX-4326
> URL: https://issues.apache.org/jira/browse/PHOENIX-4326
> Project: Phoenix
> Issue Type: Sub-task
>Reporter: Ankit Singhal
>Assignee: Ankit Singhal
> Labels: HBase-2.0
> Fix For: 5.0.0
>
>
> As 2.0.0-alpha4-SNAPSHOT is not available on a public repository. so the user
> needs to download HBase code and install the libraries in local repository by
> using maven in order to compile Phoenix code
> {code}
> git clone https://github.com/apache/hbase.git
> git checkout branch-2
> mvn clean install -DskipTests
> {code}
> We will update the HBase version to 2.0.0-alpha4 once it is released.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (PHOENIX-4290) Full table scan performed for DELETE with table having immutable indexes
[ https://issues.apache.org/jira/browse/PHOENIX-4290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Taylor updated PHOENIX-4290: -- Attachment: PHOENIX-4290_wip5.patch > Full table scan performed for DELETE with table having immutable indexes > > > Key: PHOENIX-4290 > URL: https://issues.apache.org/jira/browse/PHOENIX-4290 > Project: Phoenix > Issue Type: Bug >Reporter: James Taylor >Assignee: James Taylor > Fix For: 4.13.0, 4.12.1 > > Attachments: PHOENIX-4290_wip1.patch, PHOENIX-4290_wip2.patch, > PHOENIX-4290_wip3.patch, PHOENIX-4290_wip4.patch, PHOENIX-4290_wip5.patch > > > If a DELETE command is issued with a partial match for the leading part of > the primary key, instead of using the data table, when the table has > immutable indexes, a full scan will occur against the index. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Deleted] (PHOENIX-4327) Create branch 5.0-HBase-2.0 and update hbase.version to 2.0.0-alpha4-SNAPSHOT
[
https://issues.apache.org/jira/browse/PHOENIX-4327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ankit Singhal deleted PHOENIX-4327:
---
> Create branch 5.0-HBase-2.0 and update hbase.version to 2.0.0-alpha4-SNAPSHOT
> -
>
> Key: PHOENIX-4327
> URL: https://issues.apache.org/jira/browse/PHOENIX-4327
> Project: Phoenix
> Issue Type: Sub-task
>Reporter: Ankit Singhal
>Assignee: Ankit Singhal
> Labels: HBase-2.0
>
> As 2.0.0-alpha4-SNAPSHOT is not available on a public repository. so the user
> needs to download HBase code and install the libraries in local repository by
> using maven in order to compile Phoenix code
> {code}
> git clone https://github.com/apache/hbase.git
> git checkout branch-2
> mvn clean install -DskipTests
> {code}
> We will update the HBase version to 2.0.0-alpha4 once it is released.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (PHOENIX-4317) Update RPC controller to use the updated APIs
[ https://issues.apache.org/jira/browse/PHOENIX-4317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ankit Singhal updated PHOENIX-4317: --- Attachment: PHOENIX-4317.patch > Update RPC controller to use the updated APIs > - > > Key: PHOENIX-4317 > URL: https://issues.apache.org/jira/browse/PHOENIX-4317 > Project: Phoenix > Issue Type: Sub-task >Reporter: Ankit Singhal >Assignee: Ankit Singhal > Labels: HBase-2.0 > Fix For: 4.13.0 > > Attachments: PHOENIX-4317.patch > > > PayloadCarryingRpcController to HBaseRpcController > DelegatingPayloadCarryingRpcController to DelegatingHBaseRpcController > Update BalancedQueueRpcExecutor constructor -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (PHOENIX-4318) Fix IndexHalfStoreFileReader and related classes
[ https://issues.apache.org/jira/browse/PHOENIX-4318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ankit Singhal updated PHOENIX-4318: --- Attachment: PHOENIX-4318_wip.patch > Fix IndexHalfStoreFileReader and related classes > > > Key: PHOENIX-4318 > URL: https://issues.apache.org/jira/browse/PHOENIX-4318 > Project: Phoenix > Issue Type: Sub-task >Reporter: Ankit Singhal >Assignee: Ankit Singhal > Labels: HBase-2.0 > Fix For: 4.13.0 > > Attachments: PHOENIX-4318_wip.patch > > > These classes use the internals of HBase.(And most of them are not accessible > in HBase 2.0) > phoenix-core/src/main/java/org/apache/hadoop/hbase/regionserver/LocalIndexStoreFileScanner.java > phoenix-core/src/main/java/org/apache/hadoop/hbase/regionserver/IndexHalfStoreFileReader.java > phoenix-core/src/main/java/org/apache/hadoop/hbase/regionserver/IndexHalfStoreFileReaderGenerator.java > phoenix-core/src/main/java/org/apache/phoenix/coprocessor/DelegateRegionScanner.java > phoenix-core/src/main/java/org/apache/phoenix/util/IndexUtil.java > phoenix-core/src/main/java/org/apache/phoenix/coprocessor/DelegateRegionObserver.java -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PHOENIX-4289) UPDATE STATISTICS command does not collect stats for local indexes
[
https://issues.apache.org/jira/browse/PHOENIX-4289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16222021#comment-16222021
]
Hadoop QA commented on PHOENIX-4289:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12894299/PHOENIX-4289.patch
against master branch at commit fe13b257e5dfe29581b1c3265d79596f194954cd.
ATTACHMENT ID: 12894299
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:red}-1 lineLengths{color}. The patch introduces the following lines
longer than 100:
+private boolean hasItBeenLongEnoughSinceLastUpdateStats(PName
physicalName) throws SQLException {
+String query = "SELECT CURRENT_DATE()," + LAST_STATS_UPDATE_TIME + "
FROM " + PhoenixDatabaseMetaData.SYSTEM_STATS_NAME
++ " WHERE " + PHYSICAL_NAME + "='" + physicalName.getString()
+ "' AND " + COLUMN_FAMILY
+rowCount += updateStatisticsInternal(table.getPhysicalName(),
table, updateStatisticsStmt.getProps());
+if (index.getIndexType() != IndexType.LOCAL &&
hasItBeenLongEnoughSinceLastUpdateStats(index.getPhysicalName())) {
+rowCount +=
updateStatisticsInternal(index.getPhysicalName(), index,
updateStatisticsStmt.getProps());
+rowCount += updateStatisticsInternal(physicalName,
indexLogicalTable, updateStatisticsStmt.getProps());
+collectStatsForLocalIndexes =
hasItBeenLongEnoughSinceLastUpdateStats(physicalName);
+rowCount += updateStatisticsInternal(physicalName,
table, updateStatisticsStmt.getProps(), localCFs);
+ * Execute a COUNT(*) through PostDDLCompiler as we need to use the
logicalTable passed through,
{color:red}-1 core tests{color}. The patch failed these unit tests:
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.ViewIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.index.txn.TxWriteFailureIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.SaltedViewIT
Test results:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/1575//testReport/
Console output:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/1575//console
This message is automatically generated.
> UPDATE STATISTICS command does not collect stats for local indexes
> --
>
> Key: PHOENIX-4289
> URL: https://issues.apache.org/jira/browse/PHOENIX-4289
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.12.0
> Environment: HBase 1.3.1, Phoenix 4.12.0
>Reporter: Mujtaba Chohan
>Assignee: Samarth Jain
> Labels: localIndex
> Attachments: PHOENIX-4289.patch
>
>
> With clean {{SYSTEM.STATS}} table and restarted HBase server+Phoenix client.
> Ran {{UPDATE STATISTICS T ALL}} command. Global guidepost width is set to
> 100M. No stats are generated for any of the local indexes on table T.
> {noformat}
> explain select count(*) from T;
> +---+-++--+
> | PLAN|
> EST_BYTES_READ | EST_ROWS_READ | EST_INFO_TS |
> +---+-++--+
> | CLIENT 8-CHUNK PARALLEL 8-WAY RANGE SCAN OVER T [1] |
> null| null | null |
> | SERVER FILTER BY FIRST KEY ONLY |
> null| null | null |
> | SERVER AGGREGATE INTO SINGLE ROW |
> null| null | null |
> +---+-++--+
> select * from system.stats;
> +--++-++--++
> |PHYSICAL_NAME | COLUMN_FAMILY | GUIDE_POST_KEY |
> GUIDE_POSTS_WIDTH |
[jira] [Commented] (PHOENIX-4317) Update RPC controller to use the updated APIs
[
https://issues.apache.org/jira/browse/PHOENIX-4317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16222044#comment-16222044
]
Hadoop QA commented on PHOENIX-4317:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12894310/PHOENIX-4317.patch
against master branch at commit fe13b257e5dfe29581b1c3265d79596f194954cd.
ATTACHMENT ID: 12894310
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:red}-1 javac{color}. The patch appears to cause mvn compile goal to
fail .
Compilation errors resume:
[ERROR] COMPILATION ERROR :
[ERROR]
/home/jenkins/jenkins-slave/workspace/PreCommit-PHOENIX-Build/phoenix-core/src/main/java/org/apache/hadoop/hbase/ipc/controller/InterRegionServerIndexRpcControllerFactory.java:[26,35]
cannot find symbol
[ERROR]
/home/jenkins/jenkins-slave/workspace/PreCommit-PHOENIX-Build/phoenix-core/src/main/java/org/apache/hadoop/hbase/ipc/controller/InterRegionServerIndexRpcControllerFactory.java:[42,12]
cannot find symbol
[ERROR]
/home/jenkins/jenkins-slave/workspace/PreCommit-PHOENIX-Build/phoenix-core/src/main/java/org/apache/hadoop/hbase/ipc/controller/InterRegionServerIndexRpcControllerFactory.java:[48,12]
cannot find symbol
[ERROR]
/home/jenkins/jenkins-slave/workspace/PreCommit-PHOENIX-Build/phoenix-core/src/main/java/org/apache/hadoop/hbase/ipc/controller/InterRegionServerIndexRpcControllerFactory.java:[54,12]
cannot find symbol
[ERROR]
/home/jenkins/jenkins-slave/workspace/PreCommit-PHOENIX-Build/phoenix-core/src/main/java/org/apache/hadoop/hbase/ipc/controller/InterRegionServerIndexRpcControllerFactory.java:[59,46]
cannot find symbol
[ERROR]
/home/jenkins/jenkins-slave/workspace/PreCommit-PHOENIX-Build/phoenix-core/src/main/java/org/apache/hadoop/hbase/ipc/controller/InterRegionServerIndexRpcControllerFactory.java:[59,13]
cannot find symbol
[ERROR]
/home/jenkins/jenkins-slave/workspace/PreCommit-PHOENIX-Build/phoenix-core/src/main/java/org/apache/hadoop/hbase/ipc/controller/MetadataRpcController.java:[24,35]
cannot find symbol
[ERROR]
/home/jenkins/jenkins-slave/workspace/PreCommit-PHOENIX-Build/phoenix-core/src/main/java/org/apache/hadoop/hbase/ipc/controller/MetadataRpcController.java:[25,35]
cannot find symbol
[ERROR]
/home/jenkins/jenkins-slave/workspace/PreCommit-PHOENIX-Build/phoenix-core/src/main/java/org/apache/hadoop/hbase/ipc/controller/MetadataRpcController.java:[37,37]
cannot find symbol
[ERROR]
/home/jenkins/jenkins-slave/workspace/PreCommit-PHOENIX-Build/phoenix-core/src/main/java/org/apache/hadoop/hbase/ipc/controller/MetadataRpcController.java:[56,38]
cannot find symbol
[ERROR]
/home/jenkins/jenkins-slave/workspace/PreCommit-PHOENIX-Build/phoenix-core/src/main/java/org/apache/hadoop/hbase/ipc/controller/IndexRpcController.java:[22,35]
cannot find symbol
[ERROR]
/home/jenkins/jenkins-slave/workspace/PreCommit-PHOENIX-Build/phoenix-core/src/main/java/org/apache/hadoop/hbase/ipc/controller/IndexRpcController.java:[23,35]
cannot find symbol
[ERROR]
/home/jenkins/jenkins-slave/workspace/PreCommit-PHOENIX-Build/phoenix-core/src/main/java/org/apache/hadoop/hbase/ipc/controller/IndexRpcController.java:[34,34]
cannot find symbol
[ERROR]
/home/jenkins/jenkins-slave/workspace/PreCommit-PHOENIX-Build/phoenix-core/src/main/java/org/apache/hadoop/hbase/ipc/controller/IndexRpcController.java:[39,31]
cannot find symbol
[ERROR]
/home/jenkins/jenkins-slave/workspace/PreCommit-PHOENIX-Build/phoenix-core/src/main/java/org/apache/hadoop/hbase/ipc/controller/InterRegionServerMetadataRpcControllerFactory.java:[26,35]
cannot find symbol
[ERROR]
/home/jenkins/jenkins-slave/workspace/PreCommit-PHOENIX-Build/phoenix-core/src/main/java/org/apache/hadoop/hbase/ipc/controller/InterRegionServerMetadataRpcControllerFactory.java:[40,12]
cannot find symbol
[ERROR]
/home/jenkins/jenkins-slave/workspace/PreCommit-PHOENIX-Build/phoenix-core/src/main/java/org/apache/hadoop/hbase/ipc/controller/InterRegionServerMetadataRpcControllerFactory.java:[46,12]
cannot find symbol
[ERROR]
/home/jenkins/jenkins-slave/workspace/PreCommit-PHOENIX-Build/phoenix-core/src/main/java/org/apache/hadoop/hbase/ipc/controller/InterRegionServerMetadataRpcControllerFactory.java:[52,12]
cannot find symbol
[ERROR]
/home/jenkins/jenkins-slave/workspace/PreCommit-PHOENIX-Build/phoenix-core/src/main/java/org/apache/hadoop/hbase/ipc/controller/InterRegionServerMetadataRpcControllerFactory.java:[57,46]
cannot find symbol
[ERROR]
/home/jenkins/jenkins-slave/workspace/PreCommit-PHOENIX-Build/p
[jira] [Commented] (PHOENIX-4290) Full table scan performed for DELETE with table having immutable indexes
[
https://issues.apache.org/jira/browse/PHOENIX-4290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16222119#comment-16222119
]
Hadoop QA commented on PHOENIX-4290:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12894303/PHOENIX-4290_wip5.patch
against master branch at commit fe13b257e5dfe29581b1c3265d79596f194954cd.
ATTACHMENT ID: 12894303
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 3 new
or modified tests.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:red}-1 lineLengths{color}. The patch introduces the following lines
longer than 100:
+private void testDeleteAllFromTableWithIndex(boolean autoCommit,
boolean isSalted) throws Exception {
+private void testDeleteAllFromTableWithIndex(boolean autoCommit, boolean
isSalted, boolean localIndex) throws Exception {
+
TestUtil.dumpTable(con.unwrap(PhoenixConnection.class).getQueryServices().getTable(Bytes.toBytes(tableName)));
+
TestUtil.dumpTable(con.unwrap(PhoenixConnection.class).getQueryServices().getTable(Bytes.toBytes(tableName)));
+PreparedStatement psDelete = con.prepareStatement("DELETE FROM " +
tableName + " WHERE (HOST, DOMAIN, FEATURE, \"DATE\") = (?,?,?,?)");
+rs = con.createStatement().executeQuery("SELECT /*+ NO_INDEX */
count(*) FROM " + tableName);
+private static MutationState deleteRows(StatementContext context,
ResultIterator iterator, QueryPlan bestPlan, List otherTableRefs)
throws SQLException {
+public ImmutableBytesWritable
getLatestValue(ColumnReference ref, long ts) throws IOException {
+Cell cell =
rs.getCurrentRow().getValue(ref.getFamily(), ref.getQualifier());
+valuePtr.set(cell.getValueArray(),
cell.getValueOffset(), cell.getValueLength());
{color:red}-1 core tests{color}. The patch failed these unit tests:
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.index.LocalMutableNonTxIndexIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.IndexScrutinyToolIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.index.GlobalImmutableTxIndexIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.tx.TxCheckpointIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.execute.PartialCommitIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.index.GlobalMutableNonTxIndexIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.index.ViewIndexIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.index.LocalImmutableTxIndexIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.DeleteIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.index.LocalMutableTxIndexIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.index.GlobalMutableTxIndexIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.index.GlobalImmutableNonTxIndexIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.rpc.PhoenixClientRpcIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.join.SubqueryIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.index.LocalImmutableNonTxIndexIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.index.IndexMaintenanceIT
Test results:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/1576//testReport/
Console output:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/1576//console
This message is automatically generated.
> Full table scan performed for DELETE with table having immutable indexes
>
>
> Key: PHOENIX-4290
> URL: https://issues.apache.org/jira/browse/PHOENIX-4290
> Project: Phoenix
> Issue Type: Bug
>Reporter: James Taylor
>Assignee: James Taylor
> Fix For: 4.13.0, 4.12.1
>
> Attachments: PHOENIX-4290_wip1.patch, PHOENIX-4290_wip2.patch,
> PHOENIX-4290_wip3.patch, PHOENIX-4290_wip4.patch, PHOENIX-4290_wip5.patch
>
>
> If a DELETE command is issued with a partial match for the leading part of
> the primary key, instead of using the data table, when the table has
> immutable indexes, a full scan will occur against the index.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (PHOENIX-4198) Remove the need for users to have access to the Phoenix SYSTEM tables to create tables
[ https://issues.apache.org/jira/browse/PHOENIX-4198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1679#comment-1679 ] Ankit Singhal commented on PHOENIX-4198: Thanks [~tdsilva] and [~elserj] for the review.Updated the patch(v5) with the review comments. bq. When automatic grant is enabled you automatically grant the user who is creating the view access on the index table if they have access on the parent table. Is this required since when an index is created all users who have RWXCA access on the parent physical table are given corresponding access on the data table? Actually, this is needed when a NEW user is creating a view and Admin has just given READ/EXEC access to the user on the data table. > Remove the need for users to have access to the Phoenix SYSTEM tables to > create tables > -- > > Key: PHOENIX-4198 > URL: https://issues.apache.org/jira/browse/PHOENIX-4198 > Project: Phoenix > Issue Type: Bug >Reporter: Ankit Singhal >Assignee: Ankit Singhal > Labels: namespaces, security > Fix For: 4.13.0 > > Attachments: PHOENIX-4198.patch, PHOENIX-4198_v2.patch, > PHOENIX-4198_v3.patch, PHOENIX-4198_v4.patch > > > Problem statement:- > A user who doesn't have access to a table should also not be able to modify > Phoenix Metadata. Currently, every user required to have a write permission > to SYSTEM tables which is a security concern as they can > create/alter/drop/corrupt meta data of any other table without proper access > to the corresponding physical tables. > [~devaraj] recommended a solution as below. > 1. A coprocessor endpoint would be implemented and all write accesses to the > catalog table would have to necessarily go through that. The 'hbase' user > would own that table. Today, there is MetaDataEndpointImpl that's run on the > RS where the catalog is hosted, and that could be enhanced to serve the > purpose we need. > 2. The regionserver hosting the catalog table would do the needful for all > catalog updates - creating the mutations as needed, that is. > 3. The coprocessor endpoint could use Ranger to do necessary authorization > checks before updating the catalog table. So for example, if a user doesn't > have authorization to create a table in a certain namespace, or update the > schema, etc., it can reject such requests outright. Only after successful > validations, does it perform the operations (physical operations to do with > creating the table, and updating the catalog table with the necessary > mutations). > 4. In essence, the code that implements dealing with DDLs, would be hosted in > the catalog table endpoint. The client code would be really thin, and it > would just invoke the endpoint with the necessary info. The additional thing > that needs to be done in the endpoint is the validation of authorization to > prevent unauthorized users from making changes to someone else's > tables/schemas/etc. For example, one should be able to create a view on a > table if he has read access on the base table. That mutation on the catalog > table would be permitted. For changing the schema (adding a new column for > example), the said user would need write permission on the table... etc etc. > Thanks [~elserj] for the write-up. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (PHOENIX-4198) Remove the need for users to have access to the Phoenix SYSTEM tables to create tables
[ https://issues.apache.org/jira/browse/PHOENIX-4198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ankit Singhal updated PHOENIX-4198: --- Attachment: PHOENIX-4198_v5.patch > Remove the need for users to have access to the Phoenix SYSTEM tables to > create tables > -- > > Key: PHOENIX-4198 > URL: https://issues.apache.org/jira/browse/PHOENIX-4198 > Project: Phoenix > Issue Type: Bug >Reporter: Ankit Singhal >Assignee: Ankit Singhal > Labels: namespaces, security > Fix For: 4.13.0 > > Attachments: PHOENIX-4198.patch, PHOENIX-4198_v2.patch, > PHOENIX-4198_v3.patch, PHOENIX-4198_v4.patch, PHOENIX-4198_v5.patch > > > Problem statement:- > A user who doesn't have access to a table should also not be able to modify > Phoenix Metadata. Currently, every user required to have a write permission > to SYSTEM tables which is a security concern as they can > create/alter/drop/corrupt meta data of any other table without proper access > to the corresponding physical tables. > [~devaraj] recommended a solution as below. > 1. A coprocessor endpoint would be implemented and all write accesses to the > catalog table would have to necessarily go through that. The 'hbase' user > would own that table. Today, there is MetaDataEndpointImpl that's run on the > RS where the catalog is hosted, and that could be enhanced to serve the > purpose we need. > 2. The regionserver hosting the catalog table would do the needful for all > catalog updates - creating the mutations as needed, that is. > 3. The coprocessor endpoint could use Ranger to do necessary authorization > checks before updating the catalog table. So for example, if a user doesn't > have authorization to create a table in a certain namespace, or update the > schema, etc., it can reject such requests outright. Only after successful > validations, does it perform the operations (physical operations to do with > creating the table, and updating the catalog table with the necessary > mutations). > 4. In essence, the code that implements dealing with DDLs, would be hosted in > the catalog table endpoint. The client code would be really thin, and it > would just invoke the endpoint with the necessary info. The additional thing > that needs to be done in the endpoint is the validation of authorization to > prevent unauthorized users from making changes to someone else's > tables/schemas/etc. For example, one should be able to create a view on a > table if he has read access on the base table. That mutation on the catalog > table would be permitted. For changing the schema (adding a new column for > example), the said user would need write permission on the table... etc etc. > Thanks [~elserj] for the write-up. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (PHOENIX-4198) Remove the need for users to have access to the Phoenix SYSTEM tables to create tables
[ https://issues.apache.org/jira/browse/PHOENIX-4198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ankit Singhal updated PHOENIX-4198: --- Attachment: PHOENIX-4198_v5.patch > Remove the need for users to have access to the Phoenix SYSTEM tables to > create tables > -- > > Key: PHOENIX-4198 > URL: https://issues.apache.org/jira/browse/PHOENIX-4198 > Project: Phoenix > Issue Type: Bug >Reporter: Ankit Singhal >Assignee: Ankit Singhal > Labels: namespaces, security > Fix For: 4.13.0 > > Attachments: PHOENIX-4198.patch, PHOENIX-4198_v2.patch, > PHOENIX-4198_v3.patch, PHOENIX-4198_v4.patch, PHOENIX-4198_v5.patch > > > Problem statement:- > A user who doesn't have access to a table should also not be able to modify > Phoenix Metadata. Currently, every user required to have a write permission > to SYSTEM tables which is a security concern as they can > create/alter/drop/corrupt meta data of any other table without proper access > to the corresponding physical tables. > [~devaraj] recommended a solution as below. > 1. A coprocessor endpoint would be implemented and all write accesses to the > catalog table would have to necessarily go through that. The 'hbase' user > would own that table. Today, there is MetaDataEndpointImpl that's run on the > RS where the catalog is hosted, and that could be enhanced to serve the > purpose we need. > 2. The regionserver hosting the catalog table would do the needful for all > catalog updates - creating the mutations as needed, that is. > 3. The coprocessor endpoint could use Ranger to do necessary authorization > checks before updating the catalog table. So for example, if a user doesn't > have authorization to create a table in a certain namespace, or update the > schema, etc., it can reject such requests outright. Only after successful > validations, does it perform the operations (physical operations to do with > creating the table, and updating the catalog table with the necessary > mutations). > 4. In essence, the code that implements dealing with DDLs, would be hosted in > the catalog table endpoint. The client code would be really thin, and it > would just invoke the endpoint with the necessary info. The additional thing > that needs to be done in the endpoint is the validation of authorization to > prevent unauthorized users from making changes to someone else's > tables/schemas/etc. For example, one should be able to create a view on a > table if he has read access on the base table. That mutation on the catalog > table would be permitted. For changing the schema (adding a new column for > example), the said user would need write permission on the table... etc etc. > Thanks [~elserj] for the write-up. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (PHOENIX-4198) Remove the need for users to have access to the Phoenix SYSTEM tables to create tables
[ https://issues.apache.org/jira/browse/PHOENIX-4198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ankit Singhal updated PHOENIX-4198: --- Attachment: (was: PHOENIX-4198_v5.patch) > Remove the need for users to have access to the Phoenix SYSTEM tables to > create tables > -- > > Key: PHOENIX-4198 > URL: https://issues.apache.org/jira/browse/PHOENIX-4198 > Project: Phoenix > Issue Type: Bug >Reporter: Ankit Singhal >Assignee: Ankit Singhal > Labels: namespaces, security > Fix For: 4.13.0 > > Attachments: PHOENIX-4198.patch, PHOENIX-4198_v2.patch, > PHOENIX-4198_v3.patch, PHOENIX-4198_v4.patch, PHOENIX-4198_v5.patch > > > Problem statement:- > A user who doesn't have access to a table should also not be able to modify > Phoenix Metadata. Currently, every user required to have a write permission > to SYSTEM tables which is a security concern as they can > create/alter/drop/corrupt meta data of any other table without proper access > to the corresponding physical tables. > [~devaraj] recommended a solution as below. > 1. A coprocessor endpoint would be implemented and all write accesses to the > catalog table would have to necessarily go through that. The 'hbase' user > would own that table. Today, there is MetaDataEndpointImpl that's run on the > RS where the catalog is hosted, and that could be enhanced to serve the > purpose we need. > 2. The regionserver hosting the catalog table would do the needful for all > catalog updates - creating the mutations as needed, that is. > 3. The coprocessor endpoint could use Ranger to do necessary authorization > checks before updating the catalog table. So for example, if a user doesn't > have authorization to create a table in a certain namespace, or update the > schema, etc., it can reject such requests outright. Only after successful > validations, does it perform the operations (physical operations to do with > creating the table, and updating the catalog table with the necessary > mutations). > 4. In essence, the code that implements dealing with DDLs, would be hosted in > the catalog table endpoint. The client code would be really thin, and it > would just invoke the endpoint with the necessary info. The additional thing > that needs to be done in the endpoint is the validation of authorization to > prevent unauthorized users from making changes to someone else's > tables/schemas/etc. For example, one should be able to create a view on a > table if he has read access on the base table. That mutation on the catalog > table would be permitted. For changing the schema (adding a new column for > example), the said user would need write permission on the table... etc etc. > Thanks [~elserj] for the write-up. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (PHOENIX-4198) Remove the need for users to have access to the Phoenix SYSTEM tables to create tables
[ https://issues.apache.org/jira/browse/PHOENIX-4198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ankit Singhal updated PHOENIX-4198: --- Attachment: (was: PHOENIX-4198_v5.patch) > Remove the need for users to have access to the Phoenix SYSTEM tables to > create tables > -- > > Key: PHOENIX-4198 > URL: https://issues.apache.org/jira/browse/PHOENIX-4198 > Project: Phoenix > Issue Type: Bug >Reporter: Ankit Singhal >Assignee: Ankit Singhal > Labels: namespaces, security > Fix For: 4.13.0 > > Attachments: PHOENIX-4198.patch, PHOENIX-4198_v2.patch, > PHOENIX-4198_v3.patch, PHOENIX-4198_v4.patch > > > Problem statement:- > A user who doesn't have access to a table should also not be able to modify > Phoenix Metadata. Currently, every user required to have a write permission > to SYSTEM tables which is a security concern as they can > create/alter/drop/corrupt meta data of any other table without proper access > to the corresponding physical tables. > [~devaraj] recommended a solution as below. > 1. A coprocessor endpoint would be implemented and all write accesses to the > catalog table would have to necessarily go through that. The 'hbase' user > would own that table. Today, there is MetaDataEndpointImpl that's run on the > RS where the catalog is hosted, and that could be enhanced to serve the > purpose we need. > 2. The regionserver hosting the catalog table would do the needful for all > catalog updates - creating the mutations as needed, that is. > 3. The coprocessor endpoint could use Ranger to do necessary authorization > checks before updating the catalog table. So for example, if a user doesn't > have authorization to create a table in a certain namespace, or update the > schema, etc., it can reject such requests outright. Only after successful > validations, does it perform the operations (physical operations to do with > creating the table, and updating the catalog table with the necessary > mutations). > 4. In essence, the code that implements dealing with DDLs, would be hosted in > the catalog table endpoint. The client code would be really thin, and it > would just invoke the endpoint with the necessary info. The additional thing > that needs to be done in the endpoint is the validation of authorization to > prevent unauthorized users from making changes to someone else's > tables/schemas/etc. For example, one should be able to create a view on a > table if he has read access on the base table. That mutation on the catalog > table would be permitted. For changing the schema (adding a new column for > example), the said user would need write permission on the table... etc etc. > Thanks [~elserj] for the write-up. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (PHOENIX-4325) Make use of TableName POJO in HBase where ever possible.
[ https://issues.apache.org/jira/browse/PHOENIX-4325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajeshbabu Chintaguntla reassigned PHOENIX-4325: Assignee: Sergey Soldatov (was: Rajeshbabu Chintaguntla) > Make use of TableName POJO in HBase where ever possible. > > > Key: PHOENIX-4325 > URL: https://issues.apache.org/jira/browse/PHOENIX-4325 > Project: Phoenix > Issue Type: Sub-task >Reporter: Rajeshbabu Chintaguntla >Assignee: Sergey Soldatov > Fix For: 4.13.0 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PHOENIX-4325) Make use of TableName POJO in HBase where ever possible.
[ https://issues.apache.org/jira/browse/PHOENIX-4325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1698#comment-1698 ] Rajeshbabu Chintaguntla commented on PHOENIX-4325: -- [~sergey soldatov] assigned it to you as you have already working on it. > Make use of TableName POJO in HBase where ever possible. > > > Key: PHOENIX-4325 > URL: https://issues.apache.org/jira/browse/PHOENIX-4325 > Project: Phoenix > Issue Type: Sub-task >Reporter: Rajeshbabu Chintaguntla >Assignee: Sergey Soldatov > Fix For: 4.13.0 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (PHOENIX-4198) Remove the need for users to have access to the Phoenix SYSTEM tables to create tables
[ https://issues.apache.org/jira/browse/PHOENIX-4198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ankit Singhal updated PHOENIX-4198: --- Attachment: PHOENIX-4198_v5.patch > Remove the need for users to have access to the Phoenix SYSTEM tables to > create tables > -- > > Key: PHOENIX-4198 > URL: https://issues.apache.org/jira/browse/PHOENIX-4198 > Project: Phoenix > Issue Type: Bug >Reporter: Ankit Singhal >Assignee: Ankit Singhal > Labels: namespaces, security > Fix For: 4.13.0 > > Attachments: PHOENIX-4198.patch, PHOENIX-4198_v2.patch, > PHOENIX-4198_v3.patch, PHOENIX-4198_v4.patch, PHOENIX-4198_v5.patch > > > Problem statement:- > A user who doesn't have access to a table should also not be able to modify > Phoenix Metadata. Currently, every user required to have a write permission > to SYSTEM tables which is a security concern as they can > create/alter/drop/corrupt meta data of any other table without proper access > to the corresponding physical tables. > [~devaraj] recommended a solution as below. > 1. A coprocessor endpoint would be implemented and all write accesses to the > catalog table would have to necessarily go through that. The 'hbase' user > would own that table. Today, there is MetaDataEndpointImpl that's run on the > RS where the catalog is hosted, and that could be enhanced to serve the > purpose we need. > 2. The regionserver hosting the catalog table would do the needful for all > catalog updates - creating the mutations as needed, that is. > 3. The coprocessor endpoint could use Ranger to do necessary authorization > checks before updating the catalog table. So for example, if a user doesn't > have authorization to create a table in a certain namespace, or update the > schema, etc., it can reject such requests outright. Only after successful > validations, does it perform the operations (physical operations to do with > creating the table, and updating the catalog table with the necessary > mutations). > 4. In essence, the code that implements dealing with DDLs, would be hosted in > the catalog table endpoint. The client code would be really thin, and it > would just invoke the endpoint with the necessary info. The additional thing > that needs to be done in the endpoint is the validation of authorization to > prevent unauthorized users from making changes to someone else's > tables/schemas/etc. For example, one should be able to create a view on a > table if he has read access on the base table. That mutation on the catalog > table would be permitted. For changing the schema (adding a new column for > example), the said user would need write permission on the table... etc etc. > Thanks [~elserj] for the write-up. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (PHOENIX-4198) Remove the need for users to have access to the Phoenix SYSTEM tables to create tables
[ https://issues.apache.org/jira/browse/PHOENIX-4198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ankit Singhal updated PHOENIX-4198: --- Attachment: (was: PHOENIX-4198_v5.patch) > Remove the need for users to have access to the Phoenix SYSTEM tables to > create tables > -- > > Key: PHOENIX-4198 > URL: https://issues.apache.org/jira/browse/PHOENIX-4198 > Project: Phoenix > Issue Type: Bug >Reporter: Ankit Singhal >Assignee: Ankit Singhal > Labels: namespaces, security > Fix For: 4.13.0 > > Attachments: PHOENIX-4198.patch, PHOENIX-4198_v2.patch, > PHOENIX-4198_v3.patch, PHOENIX-4198_v4.patch > > > Problem statement:- > A user who doesn't have access to a table should also not be able to modify > Phoenix Metadata. Currently, every user required to have a write permission > to SYSTEM tables which is a security concern as they can > create/alter/drop/corrupt meta data of any other table without proper access > to the corresponding physical tables. > [~devaraj] recommended a solution as below. > 1. A coprocessor endpoint would be implemented and all write accesses to the > catalog table would have to necessarily go through that. The 'hbase' user > would own that table. Today, there is MetaDataEndpointImpl that's run on the > RS where the catalog is hosted, and that could be enhanced to serve the > purpose we need. > 2. The regionserver hosting the catalog table would do the needful for all > catalog updates - creating the mutations as needed, that is. > 3. The coprocessor endpoint could use Ranger to do necessary authorization > checks before updating the catalog table. So for example, if a user doesn't > have authorization to create a table in a certain namespace, or update the > schema, etc., it can reject such requests outright. Only after successful > validations, does it perform the operations (physical operations to do with > creating the table, and updating the catalog table with the necessary > mutations). > 4. In essence, the code that implements dealing with DDLs, would be hosted in > the catalog table endpoint. The client code would be really thin, and it > would just invoke the endpoint with the necessary info. The additional thing > that needs to be done in the endpoint is the validation of authorization to > prevent unauthorized users from making changes to someone else's > tables/schemas/etc. For example, one should be able to create a view on a > table if he has read access on the base table. That mutation on the catalog > table would be permitted. For changing the schema (adding a new column for > example), the said user would need write permission on the table... etc etc. > Thanks [~elserj] for the write-up. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (PHOENIX-4198) Remove the need for users to have access to the Phoenix SYSTEM tables to create tables
[ https://issues.apache.org/jira/browse/PHOENIX-4198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ankit Singhal updated PHOENIX-4198: --- Attachment: PHOENIX-4198_v5.patch > Remove the need for users to have access to the Phoenix SYSTEM tables to > create tables > -- > > Key: PHOENIX-4198 > URL: https://issues.apache.org/jira/browse/PHOENIX-4198 > Project: Phoenix > Issue Type: Bug >Reporter: Ankit Singhal >Assignee: Ankit Singhal > Labels: namespaces, security > Fix For: 4.13.0 > > Attachments: PHOENIX-4198.patch, PHOENIX-4198_v2.patch, > PHOENIX-4198_v3.patch, PHOENIX-4198_v4.patch, PHOENIX-4198_v5.patch > > > Problem statement:- > A user who doesn't have access to a table should also not be able to modify > Phoenix Metadata. Currently, every user required to have a write permission > to SYSTEM tables which is a security concern as they can > create/alter/drop/corrupt meta data of any other table without proper access > to the corresponding physical tables. > [~devaraj] recommended a solution as below. > 1. A coprocessor endpoint would be implemented and all write accesses to the > catalog table would have to necessarily go through that. The 'hbase' user > would own that table. Today, there is MetaDataEndpointImpl that's run on the > RS where the catalog is hosted, and that could be enhanced to serve the > purpose we need. > 2. The regionserver hosting the catalog table would do the needful for all > catalog updates - creating the mutations as needed, that is. > 3. The coprocessor endpoint could use Ranger to do necessary authorization > checks before updating the catalog table. So for example, if a user doesn't > have authorization to create a table in a certain namespace, or update the > schema, etc., it can reject such requests outright. Only after successful > validations, does it perform the operations (physical operations to do with > creating the table, and updating the catalog table with the necessary > mutations). > 4. In essence, the code that implements dealing with DDLs, would be hosted in > the catalog table endpoint. The client code would be really thin, and it > would just invoke the endpoint with the necessary info. The additional thing > that needs to be done in the endpoint is the validation of authorization to > prevent unauthorized users from making changes to someone else's > tables/schemas/etc. For example, one should be able to create a view on a > table if he has read access on the base table. That mutation on the catalog > table would be permitted. For changing the schema (adding a new column for > example), the said user would need write permission on the table... etc etc. > Thanks [~elserj] for the write-up. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PHOENIX-4198) Remove the need for users to have access to the Phoenix SYSTEM tables to create tables
[
https://issues.apache.org/jira/browse/PHOENIX-4198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16222456#comment-16222456
]
Hadoop QA commented on PHOENIX-4198:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12894376/PHOENIX-4198_v5.patch
against master branch at commit fe13b257e5dfe29581b1c3265d79596f194954cd.
ATTACHMENT ID: 12894376
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:red}-1 lineLengths{color}. The patch introduces the following lines
longer than 100:
+final UserGroupInformation superUser =
UserGroupInformation.createUserForTesting(SUPERUSER, new String[0]);
+final UserGroupInformation superUser2 =
UserGroupInformation.createUserForTesting("superuser", new String[0]);
+final UserGroupInformation regularUser =
UserGroupInformation.createUserForTesting("user", new String[0]);
+final UserGroupInformation groupUser =
UserGroupInformation.createUserForTesting("user2", new String[] {
GROUP_SYSTEM_ACCESS });
+final UserGroupInformation unprivilegedUser =
UserGroupInformation.createUserForTesting("unprivilegedUser",
+config.set("hbase.regionserver.wal.codec",
"org.apache.hadoop.hbase.regionserver.wal.IndexedWALEditCodec");
+grantPermissions(regularUser.getShortUserName(),
PHOENIX_NAMESPACE_MAPPED_SYSTEM_TABLES, Action.READ,
+grantPermissions(unprivilegedUser.getShortUserName(),
PHOENIX_NAMESPACE_MAPPED_SYSTEM_TABLES,
+grantPermissions(AuthUtil.toGroupEntry(GROUP_SYSTEM_ACCESS),
PHOENIX_NAMESPACE_MAPPED_SYSTEM_TABLES,
+grantPermissions(regularUser.getShortUserName(),
Collections.singleton("SYSTEM:SEQUENCE"), Action.WRITE,
{color:red}-1 core tests{color}. The patch failed these unit tests:
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.index.GlobalMutableTxIndexIT
Test results:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/1578//testReport/
Console output:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/1578//console
This message is automatically generated.
> Remove the need for users to have access to the Phoenix SYSTEM tables to
> create tables
> --
>
> Key: PHOENIX-4198
> URL: https://issues.apache.org/jira/browse/PHOENIX-4198
> Project: Phoenix
> Issue Type: Bug
>Reporter: Ankit Singhal
>Assignee: Ankit Singhal
> Labels: namespaces, security
> Fix For: 4.13.0
>
> Attachments: PHOENIX-4198.patch, PHOENIX-4198_v2.patch,
> PHOENIX-4198_v3.patch, PHOENIX-4198_v4.patch, PHOENIX-4198_v5.patch
>
>
> Problem statement:-
> A user who doesn't have access to a table should also not be able to modify
> Phoenix Metadata. Currently, every user required to have a write permission
> to SYSTEM tables which is a security concern as they can
> create/alter/drop/corrupt meta data of any other table without proper access
> to the corresponding physical tables.
> [~devaraj] recommended a solution as below.
> 1. A coprocessor endpoint would be implemented and all write accesses to the
> catalog table would have to necessarily go through that. The 'hbase' user
> would own that table. Today, there is MetaDataEndpointImpl that's run on the
> RS where the catalog is hosted, and that could be enhanced to serve the
> purpose we need.
> 2. The regionserver hosting the catalog table would do the needful for all
> catalog updates - creating the mutations as needed, that is.
> 3. The coprocessor endpoint could use Ranger to do necessary authorization
> checks before updating the catalog table. So for example, if a user doesn't
> have authorization to create a table in a certain namespace, or update the
> schema, etc., it can reject such requests outright. Only after successful
> validations, does it perform the operations (physical operations to do with
> creating the table, and updating the catalog table with the necessary
> mutations).
> 4. In essence, the code that implements dealing with DDLs, would be hosted in
> the catalog table endpoint. The client code would be really thin, and it
> would just invoke
[jira] [Updated] (PHOENIX-4325) Make use of TableName POJO in HBase where ever possible.
[ https://issues.apache.org/jira/browse/PHOENIX-4325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ankit Singhal updated PHOENIX-4325: --- Labels: HBase-2.0 (was: ) > Make use of TableName POJO in HBase where ever possible. > > > Key: PHOENIX-4325 > URL: https://issues.apache.org/jira/browse/PHOENIX-4325 > Project: Phoenix > Issue Type: Sub-task >Reporter: Rajeshbabu Chintaguntla >Assignee: Sergey Soldatov > Labels: HBase-2.0 > Fix For: 4.13.0 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PHOENIX-4198) Remove the need for users to have access to the Phoenix SYSTEM tables to create tables
[
https://issues.apache.org/jira/browse/PHOENIX-4198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16222559#comment-16222559
]
Hadoop QA commented on PHOENIX-4198:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12894379/PHOENIX-4198_v5.patch
against master branch at commit fe13b257e5dfe29581b1c3265d79596f194954cd.
ATTACHMENT ID: 12894379
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:red}-1 lineLengths{color}. The patch introduces the following lines
longer than 100:
+final UserGroupInformation superUser =
UserGroupInformation.createUserForTesting(SUPERUSER, new String[0]);
+final UserGroupInformation superUser2 =
UserGroupInformation.createUserForTesting("superuser", new String[0]);
+final UserGroupInformation regularUser =
UserGroupInformation.createUserForTesting("user", new String[0]);
+final UserGroupInformation groupUser =
UserGroupInformation.createUserForTesting("user2", new String[] {
GROUP_SYSTEM_ACCESS });
+final UserGroupInformation unprivilegedUser =
UserGroupInformation.createUserForTesting("unprivilegedUser",
+config.set("hbase.regionserver.wal.codec",
"org.apache.hadoop.hbase.regionserver.wal.IndexedWALEditCodec");
+grantPermissions(regularUser.getShortUserName(),
PHOENIX_NAMESPACE_MAPPED_SYSTEM_TABLES, Action.READ,
+grantPermissions(unprivilegedUser.getShortUserName(),
PHOENIX_NAMESPACE_MAPPED_SYSTEM_TABLES,
+grantPermissions(AuthUtil.toGroupEntry(GROUP_SYSTEM_ACCESS),
PHOENIX_NAMESPACE_MAPPED_SYSTEM_TABLES,
+grantPermissions(regularUser.getShortUserName(),
Collections.singleton("SYSTEM:SEQUENCE"), Action.WRITE,
{color:red}-1 core tests{color}. The patch failed these unit tests:
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.SetPropertyOnEncodedTableIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.ConcurrentMutationsIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.index.PartialIndexRebuilderIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.rpc.UpdateCacheIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.SetPropertyOnNonEncodedTableIT
Test results:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/1579//testReport/
Console output:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/1579//console
This message is automatically generated.
> Remove the need for users to have access to the Phoenix SYSTEM tables to
> create tables
> --
>
> Key: PHOENIX-4198
> URL: https://issues.apache.org/jira/browse/PHOENIX-4198
> Project: Phoenix
> Issue Type: Bug
>Reporter: Ankit Singhal
>Assignee: Ankit Singhal
> Labels: namespaces, security
> Fix For: 4.13.0
>
> Attachments: PHOENIX-4198.patch, PHOENIX-4198_v2.patch,
> PHOENIX-4198_v3.patch, PHOENIX-4198_v4.patch, PHOENIX-4198_v5.patch
>
>
> Problem statement:-
> A user who doesn't have access to a table should also not be able to modify
> Phoenix Metadata. Currently, every user required to have a write permission
> to SYSTEM tables which is a security concern as they can
> create/alter/drop/corrupt meta data of any other table without proper access
> to the corresponding physical tables.
> [~devaraj] recommended a solution as below.
> 1. A coprocessor endpoint would be implemented and all write accesses to the
> catalog table would have to necessarily go through that. The 'hbase' user
> would own that table. Today, there is MetaDataEndpointImpl that's run on the
> RS where the catalog is hosted, and that could be enhanced to serve the
> purpose we need.
> 2. The regionserver hosting the catalog table would do the needful for all
> catalog updates - creating the mutations as needed, that is.
> 3. The coprocessor endpoint could use Ranger to do necessary authorization
> checks before updating the catalog table. So for example, if a user doesn't
> have authorization to create a table in a certain namespace, or update the
> schema, etc., it can reject such requests
[jira] [Commented] (PHOENIX-4198) Remove the need for users to have access to the Phoenix SYSTEM tables to create tables
[
https://issues.apache.org/jira/browse/PHOENIX-4198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16222631#comment-16222631
]
Hadoop QA commented on PHOENIX-4198:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12894388/PHOENIX-4198_v5.patch
against master branch at commit fe13b257e5dfe29581b1c3265d79596f194954cd.
ATTACHMENT ID: 12894388
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:red}-1 lineLengths{color}. The patch introduces the following lines
longer than 100:
+final UserGroupInformation superUser =
UserGroupInformation.createUserForTesting(SUPERUSER, new String[0]);
+final UserGroupInformation superUser2 =
UserGroupInformation.createUserForTesting("superuser", new String[0]);
+final UserGroupInformation regularUser =
UserGroupInformation.createUserForTesting("user", new String[0]);
+final UserGroupInformation groupUser =
UserGroupInformation.createUserForTesting("user2", new String[] {
GROUP_SYSTEM_ACCESS });
+final UserGroupInformation unprivilegedUser =
UserGroupInformation.createUserForTesting("unprivilegedUser",
+config.set("hbase.regionserver.wal.codec",
"org.apache.hadoop.hbase.regionserver.wal.IndexedWALEditCodec");
+grantPermissions(regularUser.getShortUserName(),
PHOENIX_NAMESPACE_MAPPED_SYSTEM_TABLES, Action.READ,
+grantPermissions(unprivilegedUser.getShortUserName(),
PHOENIX_NAMESPACE_MAPPED_SYSTEM_TABLES,
+grantPermissions(AuthUtil.toGroupEntry(GROUP_SYSTEM_ACCESS),
PHOENIX_NAMESPACE_MAPPED_SYSTEM_TABLES,
+grantPermissions(regularUser.getShortUserName(),
Collections.singleton("SYSTEM:SEQUENCE"), Action.WRITE,
{color:red}-1 core tests{color}. The patch failed these unit tests:
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.ColumnEncodedImmutableTxStatsCollectorIT
Test results:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/1580//testReport/
Console output:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/1580//console
This message is automatically generated.
> Remove the need for users to have access to the Phoenix SYSTEM tables to
> create tables
> --
>
> Key: PHOENIX-4198
> URL: https://issues.apache.org/jira/browse/PHOENIX-4198
> Project: Phoenix
> Issue Type: Bug
>Reporter: Ankit Singhal
>Assignee: Ankit Singhal
> Labels: namespaces, security
> Fix For: 4.13.0
>
> Attachments: PHOENIX-4198.patch, PHOENIX-4198_v2.patch,
> PHOENIX-4198_v3.patch, PHOENIX-4198_v4.patch, PHOENIX-4198_v5.patch
>
>
> Problem statement:-
> A user who doesn't have access to a table should also not be able to modify
> Phoenix Metadata. Currently, every user required to have a write permission
> to SYSTEM tables which is a security concern as they can
> create/alter/drop/corrupt meta data of any other table without proper access
> to the corresponding physical tables.
> [~devaraj] recommended a solution as below.
> 1. A coprocessor endpoint would be implemented and all write accesses to the
> catalog table would have to necessarily go through that. The 'hbase' user
> would own that table. Today, there is MetaDataEndpointImpl that's run on the
> RS where the catalog is hosted, and that could be enhanced to serve the
> purpose we need.
> 2. The regionserver hosting the catalog table would do the needful for all
> catalog updates - creating the mutations as needed, that is.
> 3. The coprocessor endpoint could use Ranger to do necessary authorization
> checks before updating the catalog table. So for example, if a user doesn't
> have authorization to create a table in a certain namespace, or update the
> schema, etc., it can reject such requests outright. Only after successful
> validations, does it perform the operations (physical operations to do with
> creating the table, and updating the catalog table with the necessary
> mutations).
> 4. In essence, the code that implements dealing with DDLs, would be hosted in
> the catalog table endpoint. The client code would be really thin, and it
> would
[jira] [Updated] (PHOENIX-4290) Full table scan performed for DELETE with table having immutable indexes
[ https://issues.apache.org/jira/browse/PHOENIX-4290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Taylor updated PHOENIX-4290: -- Attachment: PHOENIX-4290_wip6.patch > Full table scan performed for DELETE with table having immutable indexes > > > Key: PHOENIX-4290 > URL: https://issues.apache.org/jira/browse/PHOENIX-4290 > Project: Phoenix > Issue Type: Bug >Reporter: James Taylor >Assignee: James Taylor > Fix For: 4.13.0, 4.12.1 > > Attachments: PHOENIX-4290_wip1.patch, PHOENIX-4290_wip2.patch, > PHOENIX-4290_wip3.patch, PHOENIX-4290_wip4.patch, PHOENIX-4290_wip5.patch, > PHOENIX-4290_wip6.patch > > > If a DELETE command is issued with a partial match for the leading part of > the primary key, instead of using the data table, when the table has > immutable indexes, a full scan will occur against the index. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PHOENIX-4323) LocalIndexes could fail if your data row is not in the same region as your index region
[ https://issues.apache.org/jira/browse/PHOENIX-4323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16222697#comment-16222697 ] Lars Hofhansl commented on PHOENIX-4323: We can make this less likely by appending a 0 after the region start key, before appending all the rest. I.e. now we do something like regionkey|rest, we could do regionkey|0|rest. It would still be possible to have this scenario, just much less likely. We could also have a split policy for this and or make sure that is in this case the regionEndKey and at least regionStartKey | 255. In these cases, though, we run the risk of very large regions. > LocalIndexes could fail if your data row is not in the same region as your > index region > --- > > Key: PHOENIX-4323 > URL: https://issues.apache.org/jira/browse/PHOENIX-4323 > Project: Phoenix > Issue Type: Bug >Reporter: churro morales >Assignee: Vincent Poon > Attachments: LocalIndexIT.java > > > This is not likely to happen, but if this does your data table and index > write will never succeed. > In HRegion.doMiniBatchMutation() > You create index rows in the preBatchMutate() then when you call checkRow() > on that index row the exception will bubble up if the index row is not in the > same region as your data row. > Like I said this is unlikely, but you would have to do a region merge to fix > this issue if encountered. > [~vincentpoon] has a test which he will attach to this JIRA showing an > example how this can happen. The write will never succeed unless you merge > regions if this ever happens. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
Re: [DISCUSS] Road to HBase 2.0.0
Just had an offlist chat with Sergey, Rajeshbabu, and Ankit. FYI you all will probably see a branch show up soon which includes the necessary HBase 2.0 changes (the work primarily outlined in PHOENIX-4297). This branch will probably be in a flux for a while (questionable states of compilation/test-failure). I wanted to make sure that folks who had the time/interest to contribute to the not-so-fun effort were able to ;). Will share a branch name when I see it. On 10/11/17 6:00 PM, Josh Elser wrote: Since 4.12.0 is out and we have the concurrent discussions about the 0.98, 1.1, and 1.2 HBase branches, do folks have a vision of how we get to HBase 2.0.0? The lack of chatter is pretty obvious that the Calcite work (the previous impetus for Phoenix 5) has slowed. Once we get to an HBase 2.0.0-alpha4, coprocessor API should stabilize and give us a point against which we can start Phoenix work. Should a release of Phoenix that supports HBase 2.0 be worthy of the Phoenix 5.0 label, or should we stick to the 4.x numbering? Given the breaking changes going into HBase 2.0 and James' previous -1 to shim-layers for 0.98, do we see the same for an HBase 2.0 branch or is HBase 1.x/2.x a different beast? I can see pros/cons for both sides. - Josh
[jira] [Commented] (PHOENIX-4290) Full table scan performed for DELETE with table having immutable indexes
[
https://issues.apache.org/jira/browse/PHOENIX-4290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16222747#comment-16222747
]
Hadoop QA commented on PHOENIX-4290:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12894406/PHOENIX-4290_wip6.patch
against master branch at commit fe13b257e5dfe29581b1c3265d79596f194954cd.
ATTACHMENT ID: 12894406
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 3 new
or modified tests.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:red}-1 lineLengths{color}. The patch introduces the following lines
longer than 100:
+private void testDeleteAllFromTableWithIndex(boolean autoCommit,
boolean isSalted) throws Exception {
+private void testDeleteAllFromTableWithIndex(boolean autoCommit, boolean
isSalted, boolean localIndex) throws Exception {
+
TestUtil.dumpTable(con.unwrap(PhoenixConnection.class).getQueryServices().getTable(Bytes.toBytes(tableName)));
+
TestUtil.dumpTable(con.unwrap(PhoenixConnection.class).getQueryServices().getTable(Bytes.toBytes(tableName)));
+PreparedStatement psDelete = con.prepareStatement("DELETE FROM " +
tableName + " WHERE (HOST, DOMAIN, FEATURE, \"DATE\") = (?,?,?,?)");
+rs = con.createStatement().executeQuery("SELECT /*+ NO_INDEX */
count(*) FROM " + tableName);
+private static MutationState deleteRows(StatementContext context,
ResultIterator iterator, QueryPlan bestPlan, List otherTableRefs)
throws SQLException {
+public ImmutableBytesWritable
getLatestValue(ColumnReference ref, long ts) throws IOException {
+Cell cell =
rs.getCurrentRow().getValue(ref.getFamily(), ref.getQualifier());
+valuePtr.set(cell.getValueArray(),
cell.getValueOffset(), cell.getValueLength());
{color:red}-1 core tests{color}. The patch failed these unit tests:
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.join.SubqueryIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.DeleteIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.tx.TxCheckpointIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.IntArithmeticIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.index.IndexMaintenanceIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.ConcurrentMutationsIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.index.PartialIndexRebuilderIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.QueryDatabaseMetaDataIT
Test results:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/1581//testReport/
Console output:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/1581//console
This message is automatically generated.
> Full table scan performed for DELETE with table having immutable indexes
>
>
> Key: PHOENIX-4290
> URL: https://issues.apache.org/jira/browse/PHOENIX-4290
> Project: Phoenix
> Issue Type: Bug
>Reporter: James Taylor
>Assignee: James Taylor
> Fix For: 4.13.0, 4.12.1
>
> Attachments: PHOENIX-4290_wip1.patch, PHOENIX-4290_wip2.patch,
> PHOENIX-4290_wip3.patch, PHOENIX-4290_wip4.patch, PHOENIX-4290_wip5.patch,
> PHOENIX-4290_wip6.patch
>
>
> If a DELETE command is issued with a partial match for the leading part of
> the primary key, instead of using the data table, when the table has
> immutable indexes, a full scan will occur against the index.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (PHOENIX-4290) Full table scan performed for DELETE with table having immutable indexes
[ https://issues.apache.org/jira/browse/PHOENIX-4290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Taylor updated PHOENIX-4290: -- Attachment: PHOENIX-4290_wip7.patch > Full table scan performed for DELETE with table having immutable indexes > > > Key: PHOENIX-4290 > URL: https://issues.apache.org/jira/browse/PHOENIX-4290 > Project: Phoenix > Issue Type: Bug >Reporter: James Taylor >Assignee: James Taylor > Fix For: 4.13.0, 4.12.1 > > Attachments: PHOENIX-4290_wip1.patch, PHOENIX-4290_wip2.patch, > PHOENIX-4290_wip3.patch, PHOENIX-4290_wip4.patch, PHOENIX-4290_wip5.patch, > PHOENIX-4290_wip6.patch, PHOENIX-4290_wip7.patch > > > If a DELETE command is issued with a partial match for the leading part of > the primary key, instead of using the data table, when the table has > immutable indexes, a full scan will occur against the index. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PHOENIX-4289) UPDATE STATISTICS command does not collect stats for local indexes
[
https://issues.apache.org/jira/browse/PHOENIX-4289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16222783#comment-16222783
]
James Taylor commented on PHOENIX-4289:
---
[~tdsilva] - would you have some spare cycles to review this?
> UPDATE STATISTICS command does not collect stats for local indexes
> --
>
> Key: PHOENIX-4289
> URL: https://issues.apache.org/jira/browse/PHOENIX-4289
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.12.0
> Environment: HBase 1.3.1, Phoenix 4.12.0
>Reporter: Mujtaba Chohan
>Assignee: Samarth Jain
> Labels: localIndex
> Attachments: PHOENIX-4289.patch
>
>
> With clean {{SYSTEM.STATS}} table and restarted HBase server+Phoenix client.
> Ran {{UPDATE STATISTICS T ALL}} command. Global guidepost width is set to
> 100M. No stats are generated for any of the local indexes on table T.
> {noformat}
> explain select count(*) from T;
> +---+-++--+
> | PLAN|
> EST_BYTES_READ | EST_ROWS_READ | EST_INFO_TS |
> +---+-++--+
> | CLIENT 8-CHUNK PARALLEL 8-WAY RANGE SCAN OVER T [1] |
> null| null | null |
> | SERVER FILTER BY FIRST KEY ONLY |
> null| null | null |
> | SERVER AGGREGATE INTO SINGLE ROW |
> null| null | null |
> +---+-++--+
> select * from system.stats;
> +--++-++--++
> |PHYSICAL_NAME | COLUMN_FAMILY | GUIDE_POST_KEY |
> GUIDE_POSTS_WIDTH | LAST_STATS_UPDATE_TIME | GUIDE_POSTS_ROW_COUNT |
> +--++-++--++
> | T || | null |
> 2017-10-16 18:36:57.884 | null |
> | T | 0 | [B@9bd0fa6 | 10099 |
>| 75756 |
> | T | 0 | [B@59d2103b | 10057 |
>| 75748 |
> | T | 0 | [B@39dcf4b0 | 10058 |
>| 75748 |
> | T | 0 | [B@6e4de19b | 10081 |
>| 75743 |
> | T | 0 | [B@f6c03cb | 10044 |
>| 75744 |
> | T | 0 | [B@46f699d5 | 10023 |
>| 75741 |
> | T | 0 | [B@18518ccf | 10019 |
>| 75749 |
> | T | 0 | [B@1991f767 | 10097 |
>| 75740 |
> | T | 0 | [B@768ccdc5 | 10092 |
>| 75740 |
> | T | 0 | [B@4c6daf0 | 10026 |
>| 75739 |
> | T | 0 | [B@10650953 | 10054 |
>| 75731 |
> | T | 0 | [B@659eef7 | 10092 |
>| 75741 |
> | T | 0 | [B@162be91c | 10023 |
>| 75752 |
> | T | 0 | [B@2488b073 | 10096 |
>| 75743 |
> | T | 0 | [B@1c9f0a20 | 10025 |
>| 75745 |
> | T | 0 | [B@55787112 | 10104 |
>| 75725 |
> | T | 0 | [B@1cd201a8 | 10019 |
>| 75748 |
> | T | 0 | [B@7db82169 | 10080 |
>| 75740 |
> | T | 0 | [B@1992eaf4 | 10079 |
>|
[jira] [Created] (PHOENIX-4328) Support clients having different "phoenix.schema.mapSystemTablesToNamespace" property
Karan Mehta created PHOENIX-4328:
Summary: Support clients having different
"phoenix.schema.mapSystemTablesToNamespace" property
Key: PHOENIX-4328
URL: https://issues.apache.org/jira/browse/PHOENIX-4328
Project: Phoenix
Issue Type: Bug
Reporter: Karan Mehta
Imagine a scenario when we enable namespaces for phoenix on the server side and
set the property {{phoenix.schema.isNamespaceMappingEnabled}} to true. A bunch
of clients are trying to connect to this cluster. All of these clients have
{{phoenix.schema.isNamespaceMappingEnabled}} to true, however
for some of them {{phoenix.schema.isNamespaceMappingEnabled}} is set to false
and it is true for others. (A typical case for rolling upgrade.)
The first client with {{phoenix.schema.mapSystemTablesToNamespace}} true will
acquire lock in SYSMUTEX and migrate the system tables. As soon as this
happens, all the other clients will start failing.
There are two scenarios here.
1. A new client trying to connect to server without this property set
This will fail since the ConnectionQueryServicesImpl checks if SYSCAT is
namespace mapped or not, If there is a mismatch, it throws an exception, thus
the client doesn't get any connection.
2. Clients already connected to cluster but don't have this property set
This will fail because every query calls the endpoint coprocessor on SYSCAT to
determine the PTable of the query table and the physical HBase table name is
resolved based on the properties. Thus, we try to call the method on SYSCAT
instead of SYS:CAT and it results in a TableNotFoundException.
This JIRA is to discuss about the potential ways in which we can handle this
issue.
Some ideas around this after discussing with [~twdsi...@gmail.com]:
1. Build retry logic around the code that works with SYSTEM tables (coprocessor
calls etc.) Try with SYSCAT and if it fails, try with SYS:CAT
Cons: Difficult to maintain and code scattered all over.
2. Use SchemaUtil.getPhyscialTableName method to return the table name that
actually exists. (Only for SYSTEM tables)
Call admin.tableExists to determine if SYSCAT or SYS:CAT exists and return that
name. The client properties get ignored on this one.
Cons: Expensive call every time, since this method is always called several
times.
[~jamestaylor] [~elserj] [~an...@apache.org] [~apurtell]
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (PHOENIX-4289) UPDATE STATISTICS command does not collect stats for local indexes
[
https://issues.apache.org/jira/browse/PHOENIX-4289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16222890#comment-16222890
]
Thomas D'Silva commented on PHOENIX-4289:
-
+1 LGTM
> UPDATE STATISTICS command does not collect stats for local indexes
> --
>
> Key: PHOENIX-4289
> URL: https://issues.apache.org/jira/browse/PHOENIX-4289
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.12.0
> Environment: HBase 1.3.1, Phoenix 4.12.0
>Reporter: Mujtaba Chohan
>Assignee: Samarth Jain
> Labels: localIndex
> Attachments: PHOENIX-4289.patch
>
>
> With clean {{SYSTEM.STATS}} table and restarted HBase server+Phoenix client.
> Ran {{UPDATE STATISTICS T ALL}} command. Global guidepost width is set to
> 100M. No stats are generated for any of the local indexes on table T.
> {noformat}
> explain select count(*) from T;
> +---+-++--+
> | PLAN|
> EST_BYTES_READ | EST_ROWS_READ | EST_INFO_TS |
> +---+-++--+
> | CLIENT 8-CHUNK PARALLEL 8-WAY RANGE SCAN OVER T [1] |
> null| null | null |
> | SERVER FILTER BY FIRST KEY ONLY |
> null| null | null |
> | SERVER AGGREGATE INTO SINGLE ROW |
> null| null | null |
> +---+-++--+
> select * from system.stats;
> +--++-++--++
> |PHYSICAL_NAME | COLUMN_FAMILY | GUIDE_POST_KEY |
> GUIDE_POSTS_WIDTH | LAST_STATS_UPDATE_TIME | GUIDE_POSTS_ROW_COUNT |
> +--++-++--++
> | T || | null |
> 2017-10-16 18:36:57.884 | null |
> | T | 0 | [B@9bd0fa6 | 10099 |
>| 75756 |
> | T | 0 | [B@59d2103b | 10057 |
>| 75748 |
> | T | 0 | [B@39dcf4b0 | 10058 |
>| 75748 |
> | T | 0 | [B@6e4de19b | 10081 |
>| 75743 |
> | T | 0 | [B@f6c03cb | 10044 |
>| 75744 |
> | T | 0 | [B@46f699d5 | 10023 |
>| 75741 |
> | T | 0 | [B@18518ccf | 10019 |
>| 75749 |
> | T | 0 | [B@1991f767 | 10097 |
>| 75740 |
> | T | 0 | [B@768ccdc5 | 10092 |
>| 75740 |
> | T | 0 | [B@4c6daf0 | 10026 |
>| 75739 |
> | T | 0 | [B@10650953 | 10054 |
>| 75731 |
> | T | 0 | [B@659eef7 | 10092 |
>| 75741 |
> | T | 0 | [B@162be91c | 10023 |
>| 75752 |
> | T | 0 | [B@2488b073 | 10096 |
>| 75743 |
> | T | 0 | [B@1c9f0a20 | 10025 |
>| 75745 |
> | T | 0 | [B@55787112 | 10104 |
>| 75725 |
> | T | 0 | [B@1cd201a8 | 10019 |
>| 75748 |
> | T | 0 | [B@7db82169 | 10080 |
>| 75740 |
> | T | 0 | [B@1992eaf4 | 10079 |
>| 75733 |
> | T | 0
[GitHub] phoenix issue #279: PHOENIX-3757 System mutex table not being created in SYS...
Github user twdsilva commented on the issue: https://github.com/apache/phoenix/pull/279 +1 ---
[jira] [Commented] (PHOENIX-3757) System mutex table not being created in SYSTEM namespace when namespace mapping is enabled
[
https://issues.apache.org/jira/browse/PHOENIX-3757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16222895#comment-16222895
]
ASF GitHub Bot commented on PHOENIX-3757:
-
Github user twdsilva commented on the issue:
https://github.com/apache/phoenix/pull/279
+1
> System mutex table not being created in SYSTEM namespace when namespace
> mapping is enabled
> --
>
> Key: PHOENIX-3757
> URL: https://issues.apache.org/jira/browse/PHOENIX-3757
> Project: Phoenix
> Issue Type: Bug
>Reporter: Josh Elser
>Assignee: Karan Mehta
>Priority: Critical
> Labels: namespaces
> Fix For: 4.13.0
>
> Attachments: PHOENIX-3757.001.patch, PHOENIX-3757.002.patch,
> PHOENIX-3757.003.patch, PHOENIX-3757.004.patch, PHOENIX-3757.005.patch
>
>
> Noticed this issue while writing a test for PHOENIX-3756:
> The SYSTEM.MUTEX table is always created in the default namespace, even when
> {{phoenix.schema.isNamespaceMappingEnabled=true}}. At a glance, it looks like
> the logic for the other system tables isn't applied to the mutex table.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (PHOENIX-4290) Full table scan performed for DELETE with table having immutable indexes
[
https://issues.apache.org/jira/browse/PHOENIX-4290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16222946#comment-16222946
]
Hadoop QA commented on PHOENIX-4290:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12894422/PHOENIX-4290_wip7.patch
against master branch at commit fe13b257e5dfe29581b1c3265d79596f194954cd.
ATTACHMENT ID: 12894422
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 3 new
or modified tests.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:red}-1 lineLengths{color}. The patch introduces the following lines
longer than 100:
+private static void assertIndexUsed (Connection conn, String query,
String indexName, boolean expectedToBeUsed, boolean local) throws SQLException {
+private static void assertIndexUsed (Connection conn, String query,
List binds, String indexName, boolean expectedToBeUsed, boolean local)
throws SQLException {
+assertEquals(expectedToBeUsed, explainPlan.contains(indexName
+ " [1]") || explainPlan.contains(indexName + " [1,"));
+private void testDeleteAllFromTableWithIndex(boolean autoCommit, boolean
isSalted) throws Exception {
+private void testDeleteAllFromTableWithIndex(boolean autoCommit, boolean
isSalted, boolean localIndex) throws Exception {
+
TestUtil.dumpTable(con.unwrap(PhoenixConnection.class).getQueryServices().getTable(Bytes.toBytes(tableName)));
+
TestUtil.dumpTable(con.unwrap(PhoenixConnection.class).getQueryServices().getTable(Bytes.toBytes(tableName)));
+PreparedStatement psDelete = con.prepareStatement("DELETE FROM " +
tableName + " WHERE (HOST, DOMAIN, FEATURE, \"DATE\") = (?,?,?,?)");
+rs = con.createStatement().executeQuery("SELECT /*+ NO_INDEX */
count(*) FROM " + tableName);
+conn.createStatement().execute("DELETE from " + fullDataTableName
+ " WHERE long_col2 = 2");
{color:red}-1 core tests{color}. The patch failed these unit tests:
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.LocalIndexSplitMergeIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.tx.TxCheckpointIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.join.SubqueryIT
Test results:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/1582//testReport/
Console output:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/1582//console
This message is automatically generated.
> Full table scan performed for DELETE with table having immutable indexes
>
>
> Key: PHOENIX-4290
> URL: https://issues.apache.org/jira/browse/PHOENIX-4290
> Project: Phoenix
> Issue Type: Bug
>Reporter: James Taylor
>Assignee: James Taylor
> Fix For: 4.13.0, 4.12.1
>
> Attachments: PHOENIX-4290_wip1.patch, PHOENIX-4290_wip2.patch,
> PHOENIX-4290_wip3.patch, PHOENIX-4290_wip4.patch, PHOENIX-4290_wip5.patch,
> PHOENIX-4290_wip6.patch, PHOENIX-4290_wip7.patch
>
>
> If a DELETE command is issued with a partial match for the leading part of
> the primary key, instead of using the data table, when the table has
> immutable indexes, a full scan will occur against the index.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (PHOENIX-3757) System mutex table not being created in SYSTEM namespace when namespace mapping is enabled
[
https://issues.apache.org/jira/browse/PHOENIX-3757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16223064#comment-16223064
]
Hudson commented on PHOENIX-3757:
-
SUCCESS: Integrated in Jenkins build Phoenix-master #1848 (See
[https://builds.apache.org/job/Phoenix-master/1848/])
PHOENIX-3757 System mutex table not being created in SYSTEM namespace (tdsilva:
rev 82a4dd8f78b38c0da6b019ccdead6879b87c6f26)
* (add)
phoenix-core/src/it/java/org/apache/phoenix/end2end/MigrateSystemTablesToSystemNamespaceIT.java
* (edit)
phoenix-core/src/it/java/org/apache/phoenix/end2end/SystemTablePermissionsIT.java
* (edit)
phoenix-core/src/main/java/org/apache/phoenix/query/ConnectionQueryServicesImpl.java
* (edit)
phoenix-core/src/test/java/org/apache/phoenix/query/ConnectionQueryServicesImplTest.java
* (edit)
phoenix-core/src/main/java/org/apache/phoenix/exception/UpgradeInProgressException.java
* (edit)
phoenix-core/src/main/java/org/apache/phoenix/coprocessor/MetaDataProtocol.java
* (edit) phoenix-core/src/main/java/org/apache/phoenix/util/UpgradeUtil.java
> System mutex table not being created in SYSTEM namespace when namespace
> mapping is enabled
> --
>
> Key: PHOENIX-3757
> URL: https://issues.apache.org/jira/browse/PHOENIX-3757
> Project: Phoenix
> Issue Type: Bug
>Reporter: Josh Elser
>Assignee: Karan Mehta
>Priority: Critical
> Labels: namespaces
> Fix For: 4.13.0
>
> Attachments: PHOENIX-3757.001.patch, PHOENIX-3757.002.patch,
> PHOENIX-3757.003.patch, PHOENIX-3757.004.patch, PHOENIX-3757.005.patch
>
>
> Noticed this issue while writing a test for PHOENIX-3756:
> The SYSTEM.MUTEX table is always created in the default namespace, even when
> {{phoenix.schema.isNamespaceMappingEnabled=true}}. At a glance, it looks like
> the logic for the other system tables isn't applied to the mutex table.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (PHOENIX-4290) Full table scan performed for DELETE with table having immutable indexes
[ https://issues.apache.org/jira/browse/PHOENIX-4290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Taylor updated PHOENIX-4290: -- Attachment: PHOENIX-4290_wip8.patch > Full table scan performed for DELETE with table having immutable indexes > > > Key: PHOENIX-4290 > URL: https://issues.apache.org/jira/browse/PHOENIX-4290 > Project: Phoenix > Issue Type: Bug >Reporter: James Taylor >Assignee: James Taylor > Fix For: 4.13.0, 4.12.1 > > Attachments: PHOENIX-4290_wip1.patch, PHOENIX-4290_wip2.patch, > PHOENIX-4290_wip3.patch, PHOENIX-4290_wip4.patch, PHOENIX-4290_wip5.patch, > PHOENIX-4290_wip6.patch, PHOENIX-4290_wip7.patch, PHOENIX-4290_wip8.patch > > > If a DELETE command is issued with a partial match for the leading part of > the primary key, instead of using the data table, when the table has > immutable indexes, a full scan will occur against the index. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
