[jira] [Updated] (PHOENIX-5803) Add unit testing for classes changed in PHOENIX-5801 and PHOENIX-5802
[ https://issues.apache.org/jira/browse/PHOENIX-5803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chinmay Kulkarni updated PHOENIX-5803: -- Fix Version/s: (was: 4.16.0) 4.16.1 > Add unit testing for classes changed in PHOENIX-5801 and PHOENIX-5802 > - > > Key: PHOENIX-5803 > URL: https://issues.apache.org/jira/browse/PHOENIX-5803 > Project: Phoenix > Issue Type: Improvement >Affects Versions: 5.0.0, 4.15.0 >Reporter: Chinmay Kulkarni >Priority: Major > Labels: phoenix-hardening > Fix For: 5.1.0, 4.16.1 > > > WhereConstantParser should be in the util package rather than coprocessor. > We should also refactor, remove anonymous classes, etc. in > BaseResultIterators, MutatingResultIteratorFactory, UpsertCompiler, etc. > Also need to add unit tests for all these classes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (PHOENIX-5876) IndexTool updates the index state when it runs with ONLY option
[ https://issues.apache.org/jira/browse/PHOENIX-5876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chinmay Kulkarni updated PHOENIX-5876: -- Fix Version/s: (was: 4.x) 4.16.0 > IndexTool updates the index state when it runs with ONLY option > --- > > Key: PHOENIX-5876 > URL: https://issues.apache.org/jira/browse/PHOENIX-5876 > Project: Phoenix > Issue Type: Bug >Reporter: Weiming Wang >Assignee: Weiming Wang >Priority: Minor > Fix For: 4.16.0 > > Attachments: PHOENIX-5876.4.x.001.patch, PHOENIX-5876.4.x.001.patch, > PHOENIX-5876.4.x.001.patch > > > When IndexTool runs with ONLY option, it is NOT supposed to update the index > state, since it never rebuild the index. However current code is working the > opposite way. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (PHOENIX-5872) Close Internal Phoenix Connections that were running during cancel
[ https://issues.apache.org/jira/browse/PHOENIX-5872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chinmay Kulkarni updated PHOENIX-5872: -- Fix Version/s: 4.16.0 > Close Internal Phoenix Connections that were running during cancel > -- > > Key: PHOENIX-5872 > URL: https://issues.apache.org/jira/browse/PHOENIX-5872 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.14.3, 4.x >Reporter: Daniel Wong >Assignee: Daniel Wong >Priority: Major > Fix For: 4.16.0 > > Attachments: PHOENIX-5872.4.x.patch, PHOENIX-5872.master.patch, > PHOENIX-5872v2.4.x.patch, PHOENIX-5872v3.4.x.patch, PHOENIX-5872v4.4.x.patch, > PHOENIX-5872v5.4.x.patch > > Time Spent: 6.5h > Remaining Estimate: 0h > > 3 part approach: > 1 don't count internal phoenix connections toward the client limit. > 2 count internal phoenix connections toward a newly defined limit > 3 track parent and child relationships between connections to close those > connections -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (PHOENIX-5797) RVC Offset does not work with tenant views on global indexes
[ https://issues.apache.org/jira/browse/PHOENIX-5797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chinmay Kulkarni updated PHOENIX-5797: -- Fix Version/s: 4.16.0 > RVC Offset does not work with tenant views on global indexes > > > Key: PHOENIX-5797 > URL: https://issues.apache.org/jira/browse/PHOENIX-5797 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.16.0 >Reporter: Daniel Wong >Assignee: Daniel Wong >Priority: Minor > Fix For: 4.16.0 > > Attachments: PHOENIX-5797_4.x.patch > > > Found this during use of RVC Offset in Phoenix-4845. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (PHOENIX-5698) Phoenix Query with RVC IN list expression generates wrong scan with non-pk ordered pks
[
https://issues.apache.org/jira/browse/PHOENIX-5698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chinmay Kulkarni updated PHOENIX-5698:
--
Fix Version/s: 4.16.0
> Phoenix Query with RVC IN list expression generates wrong scan with non-pk
> ordered pks
> --
>
> Key: PHOENIX-5698
> URL: https://issues.apache.org/jira/browse/PHOENIX-5698
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.15.0, 4.14.3
>Reporter: Daniel Wong
>Assignee: Xinyi Yan
>Priority: Major
> Labels: DESC
> Fix For: 4.16.0
>
> Attachments: PHOENIX-5698-4.14-HBase-1.3.patch,
> PHOENIX-5698-4.x-HBase-1.3.patch, PHOENIX-5698-4.x.patch,
> PHOENIX-5698-4.x.v3.patch, PHOENIX-5698-4.x.v4.patch,
> PHOENIX-5698-4.x.v5.patch, PHOENIX-5698-4.x.v6.patch,
> PHOENIX-5698-master.v2.patch, PHOENIX-5698.patch
>
> Time Spent: 8h
> Remaining Estimate: 0h
>
> In the code below ideally we'd expect a SINGLE ROW DELETE plan client side.
> However, this generates an incorrect scan with range ['tenant1
> 0CY005xx01Sv6o'). If the order of the RVCs is changed to row key order
> Phoenix correctly generates a SINGLE ROW SCAN. As we provide the full PK
> this we expect a either tightly bounded range scan or a client side delete.
> Instead we get a range scan on composite leading edge
> TENANT_ID,KEY_PREFIX,ID1.
>
> {code:java}
> @Test
> public void testInListExpressionWithDescAgain() throws Exception {
> String fullTableName = generateUniqueName();
> String fullViewName = generateUniqueName();
> String tenantView = generateUniqueName();
> // create base table and global view using global connection
> try (Connection conn = DriverManager.getConnection(getUrl()))
> { conn.setAutoCommit(true); Statement stmt = conn.createStatement();
> stmt.execute("CREATE TABLE " + fullTableName + "(\n" + " TENANT_ID CHAR(15)
> NOT NULL,\n" + " KEY_PREFIX CHAR(3) NOT NULL,\n" + " CONSTRAINT PK PRIMARY
> KEY (\n" + " TENANT_ID," + " KEY_PREFIX" + ")) MULTI_TENANT=TRUE");
> stmt.execute("CREATE VIEW " + fullViewName + "(\n" + " ID1 VARCHAR NOT
> NULL,\n" + " ID2 VARCHAR NOT NULL,\n" + " EVENT_DATE DATE NOT NULL,\n" + "
> CONSTRAINT PKVIEW PRIMARY KEY\n" + " (\n" + " ID1, ID2 DESC, EVENT_DATE
> DESC\n" + ")) AS SELECT * FROM " + fullTableName + " WHERE KEY_PREFIX =
> '0CY'"); }
> // create and use a tenant specific view to write data
> try (Connection viewConn = DriverManager.getConnection(TENANT_SPECIFIC_URL1)
> ) {
> viewConn.setAutoCommit(true); //need autocommit for serverside deletion
> Statement stmt = viewConn.createStatement();
> stmt.execute("CREATE VIEW IF NOT EXISTS " + tenantView + " AS SELECT * FROM
> " + fullViewName );
> viewConn.createStatement().execute("UPSERT INTO " + tenantView + "(ID1, ID2,
> EVENT_DATE) VALUES ('005xx01Sv6o', '300', 153245823)");
> viewConn.createStatement().execute("UPSERT INTO " + tenantView + "(ID1, ID2,
> EVENT_DATE) VALUES ('005xx01Sv6o', '400', 153245824)");
> viewConn.createStatement().execute("UPSERT INTO " + tenantView + "(ID1, ID2,
> EVENT_DATE) VALUES ('005xx01Sv6o', '500', 153245825)");
> viewConn.commit();
> ResultSet rs = stmt.executeQuery("SELECT ID1, ID2, EVENT_DATE FROM " +
> tenantView );
> printResultSet(rs);
> System.out.println("Delete Start");
> rs = stmt.executeQuery("EXPLAIN DELETE FROM " + tenantView + " WHERE (ID1,
> EVENT_DATE, ID2) IN (('005xx01Sv6o', 153245824,
> '400'),('005xx01Sv6o', 153245823, '300'))");
> printResultSet(rs); // THIS SHOULD BE A SINGLE ROW SCAN
> stmt.execute("DELETE FROM " + tenantView + " WHERE (ID1, EVENT_DATE, ID2) IN
> (('005xx01Sv6o', 153245824, '400'),('005xx01Sv6o',
> 153245823, '300'))");
> viewConn.commit();
> System.out.println("Delete End");
> rs = stmt.executeQuery("SELECT ID1, ID2, EVENT_DATE FROM " + tenantView );
> printResultSet(rs);
> }
> }
> private void printResultSet(ResultSet rs) throws SQLException {
> StringBuilder builder = new StringBuilder();
> while(rs.next()) {
> for(int i = 0; i < rs.getMetaData().getColumnCount(); i++) {
> Object col = rs.getObject(i + 1);
> if(col == null)
> { builder.append("null"); }
> else {
> if(col instanceof Date)
> { DateFormat df = new SimpleDateFormat("-MM-dd HH:mm:ss");
> builder.append(df.format(col)); }
> else {
> builder.append(col.toString());
> }
> }
> builder.append(",");
> }
> builder.append("\n");
> }
> System.out.println(builder.toString());
> }
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (PHOENIX-5737) Hadoop QA run says no tests even though there are added IT tests
[ https://issues.apache.org/jira/browse/PHOENIX-5737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chinmay Kulkarni updated PHOENIX-5737: -- Fix Version/s: (was: 4.15.1) > Hadoop QA run says no tests even though there are added IT tests > > > Key: PHOENIX-5737 > URL: https://issues.apache.org/jira/browse/PHOENIX-5737 > Project: Phoenix > Issue Type: Bug >Affects Versions: 5.0.0 >Reporter: Sandeep Guggilam >Assignee: Sandeep Guggilam >Priority: Minor > Fix For: 5.1.0, 4.14.4, 4.16.0 > > Attachments: PHOENIX-5737.master.patch, PHOENIX-5737.master.v1.patch > > > Even though there are ITs added in the patch, Hadoop QA run complains about > not adding any new tests -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (PHOENIX-5529) Creating a grand-child view on a table with an index fails
[
https://issues.apache.org/jira/browse/PHOENIX-5529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chinmay Kulkarni updated PHOENIX-5529:
--
Fix Version/s: (was: 4.15.1)
> Creating a grand-child view on a table with an index fails
> --
>
> Key: PHOENIX-5529
> URL: https://issues.apache.org/jira/browse/PHOENIX-5529
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.15.0, 4.14.1, 4.14.3
>Reporter: Chinmay Kulkarni
>Assignee: Abhishek Singh Chouhan
>Priority: Major
> Labels: phoenix-hardening
> Fix For: 5.1.0, 4.14.4, 4.16.0
>
> Attachments: PHOENIX-5529-master.001.patch, PHOENIX-5529-master.patch
>
>
> Steps to reproduce:
> * Build the latest Phoenix jar from the 4.x-HBase-1.3 branch.
> * Start HBase 1.3 server with above Phoenix jar in the classpath
> * Connect with a Phoenix client with above jar in classpath. From SQLLine:
> {code:sql}
> CREATE TABLE IF NOT EXISTS Z_BASE_TABLE (ID INTEGER NOT NULL PRIMARY KEY,
> HOST VARCHAR(10), FLAG BOOLEAN);
> CREATE VIEW Z_VIEW1 (col1 INTEGER, col2 INTEGER, col3 INTEGER, col4 INTEGER,
> col5 INTEGER) AS SELECT * FROM Z_BASE_TABLE WHERE ID>10;
> CREATE INDEX Z_INDEX ON Z_BASE_TABLE(HOST);
> CREATE VIEW GRAND_CHILD1 AS SELECT * FROM Z_VIEW1 WHERE col1 > 2;
> {code}
> The last step fails with the following exception:
> {code:java}
> Error: ERROR 504 (42703): Undefined column. columnName=Z_VIEW1#Z_INDEX.0:COL1
> (state=42703,code=504)
> org.apache.phoenix.schema.ColumnNotFoundException: ERROR 504 (42703):
> Undefined column. columnName=Z_VIEW1#Z_INDEX.0:COL1
> at
> org.apache.phoenix.schema.PTableImpl.getColumnForColumnName(PTableImpl.java:1076)
> at
> org.apache.phoenix.compile.FromCompiler$SingleTableColumnResolver.resolveColumn(FromCompiler.java:528)
> at
> org.apache.phoenix.compile.ExpressionCompiler.resolveColumn(ExpressionCompiler.java:368)
> at
> org.apache.phoenix.compile.WhereCompiler$WhereExpressionCompiler.resolveColumn(WhereCompiler.java:191)
> at
> org.apache.phoenix.compile.WhereCompiler$WhereExpressionCompiler.visit(WhereCompiler.java:177)
> at
> org.apache.phoenix.compile.WhereCompiler$WhereExpressionCompiler.visit(WhereCompiler.java:164)
> at
> org.apache.phoenix.parse.ColumnParseNode.accept(ColumnParseNode.java:56)
> at
> org.apache.phoenix.parse.CompoundParseNode.acceptChildren(CompoundParseNode.java:64)
> at org.apache.phoenix.parse.CastParseNode.accept(CastParseNode.java:60)
> at
> org.apache.phoenix.parse.CompoundParseNode.acceptChildren(CompoundParseNode.java:64)
> at
> org.apache.phoenix.parse.ComparisonParseNode.accept(ComparisonParseNode.java:45)
> at
> org.apache.phoenix.parse.CompoundParseNode.acceptChildren(CompoundParseNode.java:64)
> at org.apache.phoenix.parse.AndParseNode.accept(AndParseNode.java:47)
> at
> org.apache.phoenix.compile.WhereCompiler.compile(WhereCompiler.java:94)
> at
> org.apache.phoenix.util.IndexUtil.rewriteViewStatement(IndexUtil.java:549)
> at
> org.apache.phoenix.util.ViewUtil.addIndexesFromParent(ViewUtil.java:283)
> at
> org.apache.phoenix.util.ViewUtil.addDerivedColumnsAndIndexesFromParent(ViewUtil.java:531)
> at
> org.apache.phoenix.schema.MetaDataClient.addColumnsAndIndexesFromAncestors(MetaDataClient.java:859)
> at
> org.apache.phoenix.schema.MetaDataClient.addTableToCache(MetaDataClient.java:4456)
> at
> org.apache.phoenix.schema.MetaDataClient.addTableToCache(MetaDataClient.java:4452)
> at
> org.apache.phoenix.schema.MetaDataClient.createTableInternal(MetaDataClient.java:3004)
> at
> org.apache.phoenix.schema.MetaDataClient.createTable(MetaDataClient.java:1049)
> at
> org.apache.phoenix.compile.CreateTableCompiler$1.execute(CreateTableCompiler.java:217)
> at
> org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:411)
> at
> org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:394)
> at org.apache.phoenix.call.CallRunner.run(CallRunner.java:53)
> at
> org.apache.phoenix.jdbc.PhoenixStatement.executeMutation(PhoenixStatement.java:393)
> at
> org.apache.phoenix.jdbc.PhoenixStatement.executeMutation(PhoenixStatement.java:381)
> at
> org.apache.phoenix.jdbc.PhoenixStatement.execute(PhoenixStatement.java:1843)
> at sqlline.Commands.execute(Commands.java:814)
> at sqlline.Commands.sql(Commands.java:754)
> at sqlline.SqlLine.dispatch(SqlLine.java:646)
> at sqlline.SqlLine.begin(SqlLine.java:510)
> at sqlline.SqlLine.start(SqlLine.java:233)
> at sqlline.SqlLine.main(SqlLine.java:175)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (PHOENIX-5723) PhoenixIndexImportDirectReducer cleanup method updates index state to active
[ https://issues.apache.org/jira/browse/PHOENIX-5723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chinmay Kulkarni updated PHOENIX-5723: -- Fix Version/s: 4.16.0 > PhoenixIndexImportDirectReducer cleanup method updates index state to active > > > Key: PHOENIX-5723 > URL: https://issues.apache.org/jira/browse/PHOENIX-5723 > Project: Phoenix > Issue Type: Bug >Reporter: Tanuj Khurana >Assignee: Tanuj Khurana >Priority: Minor > Fix For: 4.16.0 > > Attachments: PHOENIX-5723.4.x-HBase-1.3.v1.patch, > PHOENIX-5723.master.v1.patch > > Time Spent: 2h > Remaining Estimate: 0h > > The cleanup() method on PhoenixIndexImportDirectReducer updates the index > state to active. The cleanup() method is called even if the reduce() method > throws an exception. We need to move the index update to reduce() method. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (PHOENIX-5697) Avoid resource leakage with try-with-resources
[ https://issues.apache.org/jira/browse/PHOENIX-5697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chinmay Kulkarni updated PHOENIX-5697: -- Fix Version/s: (was: 4.15.1) > Avoid resource leakage with try-with-resources > -- > > Key: PHOENIX-5697 > URL: https://issues.apache.org/jira/browse/PHOENIX-5697 > Project: Phoenix > Issue Type: Improvement >Affects Versions: 5.1.0, 4.15.1 >Reporter: Viraj Jasani >Assignee: Viraj Jasani >Priority: Major > Labels: phoenix-hardening > Fix For: 5.1.0, 4.14.4, 4.16.0 > > Attachments: PHOENIX-5697.4.x-HBase-1.5.000.patch, > PHOENIX-5697.master.000.patch > > Time Spent: 0.5h > Remaining Estimate: 0h > > There are places where we catch IOException in finally block while closing a > closable resource or have to do redundant null check. If we could use > try-with-resources to deal with closure of resources, that would not let us > worry about catching IOException or NPE while closing the resources and would > be a better replacement. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (PHOENIX-5112) Simplify QueryPlan selection in Phoenix
[
https://issues.apache.org/jira/browse/PHOENIX-5112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chinmay Kulkarni updated PHOENIX-5112:
--
Summary: Simplify QueryPlan selection in Phoenix (was: Simplify QueryPlan
selection in Phoenix.)
> Simplify QueryPlan selection in Phoenix
> ---
>
> Key: PHOENIX-5112
> URL: https://issues.apache.org/jira/browse/PHOENIX-5112
> Project: Phoenix
> Issue Type: Improvement
>Affects Versions: 4.15.0, 5.1.0
>Reporter: Lars Hofhansl
>Assignee: Lars Hofhansl
>Priority: Major
> Fix For: 4.15.0, 5.1.0
>
> Attachments: 5112-master.txt, 5112-master.txt
>
>
> Brought to light in part in PHOENIX-5109, plan selection in Phoenix is too
> complicated with its logic spread over multiple areas. My recent changes let
> most index through the initial filters and next step is to put all the logic
> in {{QueryOptimizer.orderPlansBestToWorst}}.
> One exception is plans with global indexes for queries with uncovered
> queries, those should still be handled in {{addPlan}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (PHOENIX-5190) Implement a TaskRegionObserver for index rebuilds
[ https://issues.apache.org/jira/browse/PHOENIX-5190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chinmay Kulkarni updated PHOENIX-5190: -- Fix Version/s: 4.15.0 > Implement a TaskRegionObserver for index rebuilds > - > > Key: PHOENIX-5190 > URL: https://issues.apache.org/jira/browse/PHOENIX-5190 > Project: Phoenix > Issue Type: Improvement >Reporter: Gokcen Iskender >Assignee: Gokcen Iskender >Priority: Major > Fix For: 4.15.0 > > Attachments: PHOENIX-5190-4.x.patch, PHOENIX-5190.patch > > Time Spent: 3h 10m > Remaining Estimate: 0h > > A new way to kick index rebuilds is putting an entry to System.Tasks table. > IndexRebuildTask is a new TaskRegionObserver. It will look at this table, > kick the index rebuild and mark the task status. > This work requires updates to the System.Tasks table. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (PHOENIX-5842) Code Coverage tool for Phoenix
[ https://issues.apache.org/jira/browse/PHOENIX-5842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sandeep Guggilam updated PHOENIX-5842: -- Attachment: PHOENIX-5842.4.x.v2.patch > Code Coverage tool for Phoenix > -- > > Key: PHOENIX-5842 > URL: https://issues.apache.org/jira/browse/PHOENIX-5842 > Project: Phoenix > Issue Type: Improvement >Reporter: Sandeep Guggilam >Assignee: Sandeep Guggilam >Priority: Major > Labels: quality-improvement > Attachments: PHOENIX-5842.4.x.v1.patch, PHOENIX-5842.4.x.v2.patch > > > Currently we don't have any code coverage tool for Phoenix. This is required > for us to measure the test coverage and helps us in improving the test suite > further till we reach may be 80% coverage > The test coverage results can also be integrated into the Hadoop QA run of > the precommit build such that the reviewers could take a look at the report > and see if the added code doesn't have enough coverage -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (PHOENIX-5842) Code Coverage tool for Phoenix
[ https://issues.apache.org/jira/browse/PHOENIX-5842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sandeep Guggilam updated PHOENIX-5842: -- Attachment: (was: PHOENIX-5842.4.x.v2.patch) > Code Coverage tool for Phoenix > -- > > Key: PHOENIX-5842 > URL: https://issues.apache.org/jira/browse/PHOENIX-5842 > Project: Phoenix > Issue Type: Improvement >Reporter: Sandeep Guggilam >Assignee: Sandeep Guggilam >Priority: Major > Labels: quality-improvement > Attachments: PHOENIX-5842.4.x.v1.patch, PHOENIX-5842.4.x.v2.patch > > > Currently we don't have any code coverage tool for Phoenix. This is required > for us to measure the test coverage and helps us in improving the test suite > further till we reach may be 80% coverage > The test coverage results can also be integrated into the Hadoop QA run of > the precommit build such that the reviewers could take a look at the report > and see if the added code doesn't have enough coverage -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (PHOENIX-4825) Replace usage of HBase Base64 implementation with java.util.Base64
[ https://issues.apache.org/jira/browse/PHOENIX-4825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chinmay Kulkarni updated PHOENIX-4825: -- Fix Version/s: 4.15.0 > Replace usage of HBase Base64 implementation with java.util.Base64 > -- > > Key: PHOENIX-4825 > URL: https://issues.apache.org/jira/browse/PHOENIX-4825 > Project: Phoenix > Issue Type: Task >Reporter: Ankit Singhal >Assignee: Ankit Singhal >Priority: Blocker > Fix For: 4.15.0, 5.1.0 > > Attachments: PHOENIX-4825.patch > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (PHOENIX-4824) Update BRANCH_NAMES in dev/test-patch.properties
[ https://issues.apache.org/jira/browse/PHOENIX-4824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chinmay Kulkarni updated PHOENIX-4824: -- Fix Version/s: 4.16.0 > Update BRANCH_NAMES in dev/test-patch.properties > > > Key: PHOENIX-4824 > URL: https://issues.apache.org/jira/browse/PHOENIX-4824 > Project: Phoenix > Issue Type: Bug >Reporter: Thomas D'Silva >Assignee: Thomas D'Silva >Priority: Major > Fix For: 4.16.0 > > Attachments: PHOENIX-4824-v2.patch, PHOENIX-4824.patch > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (PHOENIX-4824) Update BRANCH_NAMES in dev/test-patch.properties
[ https://issues.apache.org/jira/browse/PHOENIX-4824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chinmay Kulkarni updated PHOENIX-4824: -- Fix Version/s: (was: 4.16.0) > Update BRANCH_NAMES in dev/test-patch.properties > > > Key: PHOENIX-4824 > URL: https://issues.apache.org/jira/browse/PHOENIX-4824 > Project: Phoenix > Issue Type: Bug >Reporter: Thomas D'Silva >Assignee: Thomas D'Silva >Priority: Major > Attachments: PHOENIX-4824-v2.patch, PHOENIX-4824.patch > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (PHOENIX-5703) Add MAVEN_HOME toPATH in jenkins build
[ https://issues.apache.org/jira/browse/PHOENIX-5703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chinmay Kulkarni updated PHOENIX-5703: -- Fix Version/s: (was: 4.14.4) (was: 4.15.1) > Add MAVEN_HOME toPATH in jenkins build > -- > > Key: PHOENIX-5703 > URL: https://issues.apache.org/jira/browse/PHOENIX-5703 > Project: Phoenix > Issue Type: Improvement >Reporter: Sandeep Guggilam >Assignee: Sandeep Guggilam >Priority: Major > Fix For: 5.1.0, 4.16.0 > > Attachments: PHOENIX-5703.4.x-HBase-1.3.v1.patch, > PHOENIX-5703.4.x-HBase-1.4.v1.patch, PHOENIX-5703.4.x-HBase-1.5.v1.patch, > PHOENIX-5703.master.v1.patch, PHOENIX-5703.master.v2.patch > > > We need to add MAVEN_HOME to PATH in Jenkins build for us to be able to run > any mvn commands as part of any test -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (PHOENIX-5654) String values (ALWAYS and NEVER) don't work for connection level config phoenix.default.update.cache.frequency
[
https://issues.apache.org/jira/browse/PHOENIX-5654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chinmay Kulkarni updated PHOENIX-5654:
--
Fix Version/s: (was: 4.15.1)
4.16.0
> String values (ALWAYS and NEVER) don't work for connection level config
> phoenix.default.update.cache.frequency
> --
>
> Key: PHOENIX-5654
> URL: https://issues.apache.org/jira/browse/PHOENIX-5654
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.15.0, 5.1.0
>Reporter: Nitesh Maheshwari
>Assignee: Nitesh Maheshwari
>Priority: Major
> Fix For: 5.1.0, 4.16.0
>
> Attachments: PHOENIX-5654.4.x-HBase-1.3.v1.patch,
> PHOENIX-5654.4.x-HBase-1.3.v2.patch, PHOENIX-5654.4.x-HBase-1.3.v3.patch,
> PHOENIX-5654.master.v1.patch, PHOENIX-5654.master.v2.patch,
> PHOENIX-5654.master.v3.patch, PHOENIX-5654.master.v4.patch
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> While working on PHOENIX-5634, I noticed that the connection level property
> 'phoenix.default.update.cache.frequency' is being read in
> 'MetadataClient::createTable()' and 'Metadata::createTableInternal()' as
> follows:
> {code:java}
> long updateCacheFrequency = connection.getQueryServices().getProps().getLong(
> QueryServices.DEFAULT_UPDATE_CACHE_FREQUENCY_ATRRIB,
> QueryServicesOptions.DEFAULT_UPDATE_CACHE_FREQUENCY);
> {code}
> However, looking at the documentation for option 'UPDATE_CACHE_FREQUENCY' at
> [https://phoenix.apache.org/language/index.html], the value for this config
> could also be set to strings 'ALWAYS' and 'NEVER'. The use of getLong() above
> will always return 'QueryServicesOptions.DEFAULT_UPDATE_CACHE_FREQUENCY' when
> the config is set to 'ALWAYS'/'NEVER'. Reading the connection-level property
> should also follow the way the table-level property is read in
> 'TableProperty.UPDATE_CACHE_FREQUENCY'.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (PHOENIX-5655) ServerCache using table map is not correctly removed
[ https://issues.apache.org/jira/browse/PHOENIX-5655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chinmay Kulkarni updated PHOENIX-5655: -- Fix Version/s: (was: 4.15.1) 4.16.0 > ServerCache using table map is not correctly removed > > > Key: PHOENIX-5655 > URL: https://issues.apache.org/jira/browse/PHOENIX-5655 > Project: Phoenix > Issue Type: Bug >Affects Versions: 5.1.0 >Reporter: Viraj Jasani >Assignee: Viraj Jasani >Priority: Major > Fix For: 5.1.0, 4.16.0 > > Attachments: PHOENIX-5655.4.x-HBase-1.5.000.patch, > PHOENIX-5655.master.000.patch, PHOENIX-5655.master.002.patch, > PHOENIX-5655.master.003.patch, PHOENIX-5655.master.004.patch > > > ServerCacheClient should remove cacheId -> PTable map entry while removing > cached table from all RegionServers, which is not happening correctly. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (PHOENIX-5274) ConnectionQueryServiceImpl#ensureNamespaceCreated and ensureTableCreated should use HBase APIs that do not require ADMIN permissions for existence checks
[ https://issues.apache.org/jira/browse/PHOENIX-5274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chinmay Kulkarni updated PHOENIX-5274: -- Fix Version/s: (was: 4.15.1) > ConnectionQueryServiceImpl#ensureNamespaceCreated and ensureTableCreated > should use HBase APIs that do not require ADMIN permissions for existence > checks > - > > Key: PHOENIX-5274 > URL: https://issues.apache.org/jira/browse/PHOENIX-5274 > Project: Phoenix > Issue Type: Improvement >Affects Versions: 5.0.0, 4.15.0, 4.14.2 >Reporter: Chinmay Kulkarni >Assignee: Ankit Jain >Priority: Major > Fix For: 5.0.0, 4.16.0 > > Attachments: PHOENIX-5274.4.x-HBase-1.5.v1.patch, > PHOENIX-5274.4.x-HBase-1.5.v2.patch, PHOENIX-5274.4.x-HBase-1.5.v3.patch > > Time Spent: 1h 10m > Remaining Estimate: 0h > > [HBASE-22377|https://issues.apache.org/jira/browse/HBASE-22377] will > introduce a new API that does not require ADMIN permissions to check the > existence of a namespace. > Currently, CQSI#ensureNamespaceCreated calls > HBaseAdmin#getNamespaceDescriptor which eventually on the server causes a > call to AccessController#preGetNamespaceDescriptor. This tries to acquire > ADMIN permissions on the namespace. We should ideally use the new API > provided by HBASE-22377 which does not require the phoenix client to get > ADMIN permissions on the namespace. We should acquire ADMIN permissions only > in case we need to create the namespace if it doesn't already exist. > Similarly, CQSI#ensureTableCreated should first check the existence of a > table before trying to do HBaseAdmin#getTableDescriptor since this requires > CREATE and ADMIN permissions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (PHOENIX-5274) ConnectionQueryServiceImpl#ensureNamespaceCreated and ensureTableCreated should use HBase APIs that do not require ADMIN permissions for existence checks
[ https://issues.apache.org/jira/browse/PHOENIX-5274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chinmay Kulkarni updated PHOENIX-5274: -- Fix Version/s: 4.16.0 > ConnectionQueryServiceImpl#ensureNamespaceCreated and ensureTableCreated > should use HBase APIs that do not require ADMIN permissions for existence > checks > - > > Key: PHOENIX-5274 > URL: https://issues.apache.org/jira/browse/PHOENIX-5274 > Project: Phoenix > Issue Type: Improvement >Affects Versions: 5.0.0, 4.15.0, 4.14.2 >Reporter: Chinmay Kulkarni >Assignee: Ankit Jain >Priority: Major > Fix For: 5.0.0, 4.15.1, 4.16.0 > > Attachments: PHOENIX-5274.4.x-HBase-1.5.v1.patch, > PHOENIX-5274.4.x-HBase-1.5.v2.patch, PHOENIX-5274.4.x-HBase-1.5.v3.patch > > Time Spent: 1h 10m > Remaining Estimate: 0h > > [HBASE-22377|https://issues.apache.org/jira/browse/HBASE-22377] will > introduce a new API that does not require ADMIN permissions to check the > existence of a namespace. > Currently, CQSI#ensureNamespaceCreated calls > HBaseAdmin#getNamespaceDescriptor which eventually on the server causes a > call to AccessController#preGetNamespaceDescriptor. This tries to acquire > ADMIN permissions on the namespace. We should ideally use the new API > provided by HBASE-22377 which does not require the phoenix client to get > ADMIN permissions on the namespace. We should acquire ADMIN permissions only > in case we need to create the namespace if it doesn't already exist. > Similarly, CQSI#ensureTableCreated should first check the existence of a > table before trying to do HBaseAdmin#getTableDescriptor since this requires > CREATE and ADMIN permissions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (PHOENIX-5884) Join query return empty result when filters for both the tables are present
[
https://issues.apache.org/jira/browse/PHOENIX-5884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ankit Singhal updated PHOENIX-5884:
---
Attachment: PHOENIX-5884_v1.patch
> Join query return empty result when filters for both the tables are present
> ---
>
> Key: PHOENIX-5884
> URL: https://issues.apache.org/jira/browse/PHOENIX-5884
> Project: Phoenix
> Issue Type: Bug
>Reporter: Ankit Singhal
>Assignee: Ankit Singhal
>Priority: Major
> Attachments: PHOENIX-5884_v1.patch
>
>
> Let's assume DDL to be same for both the tables involved in a join
> {code}
> CREATE TABLE LeftTable (id1 CHAR(6) NOT NULL,id2 VARCHAR(22) NOT
> NULL,id3 VARCHAR(12) NOT NULL,id4 CHAR(2) NOT NULL,id5 CHAR(6)
> NOT NULL, id6 VARCHAR(200) NOT NULL,id7 VARCHAR(50) NOT NULL,ts
> TIMESTAMP ,CONSTRAINT PK_JOIN_AND_INTERSECTION_TABLE PRIMARY
> KEY(id1,id2,id3,id4,id5,id6,id7))
> {code}
> Following query return right results
> {code}
> SELECT m.*,r.* FROM LEFT_TABLE m join RIGHT_TABLE r on m.id3 = r.id3 and
> m.id2 = r.id2 and m.id4 = r.id4 and m.id5 = r.id5 and m.id1 = r.id1 and
> m.ts = r.ts where r.id1 IN ('201904','201905') and r.id2 = 'ID2_VAL' and
> r.id3 IN ('ID3_VAL','ID3_VAL2')
> {code}
> but When to optimize the query, filters for the left table are also added ,
> query returned empty result . Though the filters are based on join condition
> so semantically above query and below query should be same.
> {code}
> SELECT m.*,r.* FROM LEFT_TABLE m join RIGHT_TABLE r on m.id3 = r.id3 and
> m.id2 = r.id2 and m.id4 = r.id4 and m.id5 = r.id5 and m.id1 = r.id1 and
> m.ts = r.ts where m.id1 IN ('201904','201905') and r.id1 IN
> ('201904','201905') and r.id2 = 'ID2_VAL' and m.id3 IN
> ('ID3_VAL','ID3_VAL2') and r.id3 IN ('ID3_VAL','ID3_VAL2')
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (PHOENIX-5884) Join query return empty result when filters for both the tables are present
[
https://issues.apache.org/jira/browse/PHOENIX-5884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ankit Singhal updated PHOENIX-5884:
---
Description:
Let's assume DDL to be same for both the tables involved in a join
{code}
CREATE TABLE LeftTable (id1 CHAR(6) NOT NULL,id2 VARCHAR(22) NOT NULL,
id3 VARCHAR(12) NOT NULL,id4 CHAR(2) NOT NULL,id5 CHAR(6) NOT NULL,
id6 VARCHAR(200) NOT NULL,id7 VARCHAR(50) NOT NULL,ts TIMESTAMP ,
CONSTRAINT PK_JOIN_AND_INTERSECTION_TABLE PRIMARY
KEY(id1,id2,id3,id4,id5,id6,id7))
{code}
Following query return right results
{code}
SELECT m.*,r.* FROM LEFT_TABLE m join RIGHT_TABLE r on m.id3 = r.id3 and m.id2
= r.id2 and m.id4 = r.id4 and m.id5 = r.id5 and m.id1 = r.id1 and m.ts =
r.ts where r.id1 IN ('201904','201905') and r.id2 = 'ID2_VAL' and r.id3 IN
('ID3_VAL','ID3_VAL2')
{code}
but When to optimize the query, filters for the left table are also added ,
query returned empty result . Though the filters are based on join condition so
semantically above query and below query should be same.
{code}
SELECT m.*,r.* FROM LEFT_TABLE m join RIGHT_TABLE r on m.id3 = r.id3 and
m.id2 = r.id2 and m.id4 = r.id4 and m.id5 = r.id5 and m.id1 = r.id1 and m.ts
= r.ts where m.id1 IN ('201904','201905') and r.id1 IN ('201904','201905')
and r.id2 = 'ID2_VAL' and m.id3 IN ('ID3_VAL','ID3_VAL2') and
r.id3 IN ('ID3_VAL','ID3_VAL2')
{code}
was:
Let's assume DDL to be same for both the tables involved in a join
{code}
CREATE TABLE LeftTable (id1 CHAR(6) NOT NULL,id2 VARCHAR(22) NOT NULL,
id3 VARCHAR(12) NOT NULL,id4 CHAR(2) NOT NULL,id5 CHAR(6) NOT NULL,
id6 VARCHAR(200) NOT NULL,id7 VARCHAR(50) NOT NULL,ts TIMESTAMP ,
CONSTRAINT PK_JOIN_AND_INTERSECTION_TABLE PRIMARY
KEY(id1,id2,id3,id4,id5,id6,id7))
{code}
Following query return right results
{code}
SELECT m.*,r.* FROM LEFT_TABLE m join RIGHT_TABLE r on m.id3 = r.id3 and m.id2
= r.id2 and m.id4 = r.id4 and m.id5 = r.id5 and m.id1 = r.id1 and m.ts =
r.ts where r.id1 IN ('201904','201905') and r.id2 = 'ID2_VAL' and r.id3 IN
('ID3_VAL','ID3_VAL2')
{code
but When to optimize the query, filters for the left table are also added ,
query returned empty result . Though the filters are based on join condition so
semantically above query and below query should be same.
{code}
SELECT m.*,r.* FROM LEFT_TABLE m join RIGHT_TABLE r on m.id3 = r.id3 and
m.id2 = r.id2 and m.id4 = r.id4 and m.id5 = r.id5 and m.id1 = r.id1 and m.ts
= r.ts where m.id1 IN ('201904','201905') and r.id1 IN ('201904','201905')
and r.id2 = 'ID2_VAL' and m.id3 IN ('ID3_VAL','ID3_VAL2') and
r.id3 IN ('ID3_VAL','ID3_VAL2')
{code}
> Join query return empty result when filters for both the tables are present
> ---
>
> Key: PHOENIX-5884
> URL: https://issues.apache.org/jira/browse/PHOENIX-5884
> Project: Phoenix
> Issue Type: Bug
>Reporter: Ankit Singhal
>Assignee: Ankit Singhal
>Priority: Major
>
> Let's assume DDL to be same for both the tables involved in a join
> {code}
> CREATE TABLE LeftTable (id1 CHAR(6) NOT NULL,id2 VARCHAR(22) NOT
> NULL,id3 VARCHAR(12) NOT NULL,id4 CHAR(2) NOT NULL,id5 CHAR(6)
> NOT NULL, id6 VARCHAR(200) NOT NULL,id7 VARCHAR(50) NOT NULL,ts
> TIMESTAMP ,CONSTRAINT PK_JOIN_AND_INTERSECTION_TABLE PRIMARY
> KEY(id1,id2,id3,id4,id5,id6,id7))
> {code}
> Following query return right results
> {code}
> SELECT m.*,r.* FROM LEFT_TABLE m join RIGHT_TABLE r on m.id3 = r.id3 and
> m.id2 = r.id2 and m.id4 = r.id4 and m.id5 = r.id5 and m.id1 = r.id1 and
> m.ts = r.ts where r.id1 IN ('201904','201905') and r.id2 = 'ID2_VAL' and
> r.id3 IN ('ID3_VAL','ID3_VAL2')
> {code}
> but When to optimize the query, filters for the left table are also added ,
> query returned empty result . Though the filters are based on join condition
> so semantically above query and below query should be same.
> {code}
> SELECT m.*,r.* FROM LEFT_TABLE m join RIGHT_TABLE r on m.id3 = r.id3 and
> m.id2 = r.id2 and m.id4 = r.id4 and m.id5 = r.id5 and m.id1 = r.id1 and
> m.ts = r.ts where m.id1 IN ('201904','201905') and r.id1 IN
> ('201904','201905') and r.id2 = 'ID2_VAL' and m.id3 IN
> ('ID3_VAL','ID3_VAL2') and r.id3 IN ('ID3_VAL','ID3_VAL2')
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (PHOENIX-5884) Join query return empty result when filters for both the tables are present
Ankit Singhal created PHOENIX-5884:
--
Summary: Join query return empty result when filters for both the
tables are present
Key: PHOENIX-5884
URL: https://issues.apache.org/jira/browse/PHOENIX-5884
Project: Phoenix
Issue Type: Bug
Reporter: Ankit Singhal
Assignee: Ankit Singhal
Let's assume DDL to be same for both the tables involved in a join
{code}
CREATE TABLE LeftTable (id1 CHAR(6) NOT NULL,id2 VARCHAR(22) NOT NULL,
id3 VARCHAR(12) NOT NULL,id4 CHAR(2) NOT NULL,id5 CHAR(6) NOT NULL,
id6 VARCHAR(200) NOT NULL,id7 VARCHAR(50) NOT NULL,ts TIMESTAMP ,
CONSTRAINT PK_JOIN_AND_INTERSECTION_TABLE PRIMARY
KEY(id1,id2,id3,id4,id5,id6,id7))
{code}
Following query return right results
{code}
SELECT m.*,r.* FROM LEFT_TABLE m join RIGHT_TABLE r on m.id3 = r.id3 and m.id2
= r.id2 and m.id4 = r.id4 and m.id5 = r.id5 and m.id1 = r.id1 and m.ts =
r.ts where r.id1 IN ('201904','201905') and r.id2 = 'ID2_VAL' and r.id3 IN
('ID3_VAL','ID3_VAL2')
{code
but When to optimize the query, filters for the left table are also added ,
query returned empty result . Though the filters are based on join condition so
semantically above query and below query should be same.
{code}
SELECT m.*,r.* FROM LEFT_TABLE m join RIGHT_TABLE r on m.id3 = r.id3 and
m.id2 = r.id2 and m.id4 = r.id4 and m.id5 = r.id5 and m.id1 = r.id1 and m.ts
= r.ts where m.id1 IN ('201904','201905') and r.id1 IN ('201904','201905')
and r.id2 = 'ID2_VAL' and m.id3 IN ('ID3_VAL','ID3_VAL2') and
r.id3 IN ('ID3_VAL','ID3_VAL2')
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (PHOENIX-5862) Ensure that we handle all server-side mutation codes on the client
[ https://issues.apache.org/jira/browse/PHOENIX-5862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Neha Gupta updated PHOENIX-5862: Fix Version/s: (was: 4.16.0) > Ensure that we handle all server-side mutation codes on the client > -- > > Key: PHOENIX-5862 > URL: https://issues.apache.org/jira/browse/PHOENIX-5862 > Project: Phoenix > Issue Type: Bug >Reporter: Neha Gupta >Priority: Major > > More details in > https://issues.apache.org/jira/browse/PHOENIX-5496 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (PHOENIX-5842) Code Coverage tool for Phoenix
[ https://issues.apache.org/jira/browse/PHOENIX-5842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sandeep Guggilam updated PHOENIX-5842: -- Attachment: PHOENIX-5842.4.x.v2.patch > Code Coverage tool for Phoenix > -- > > Key: PHOENIX-5842 > URL: https://issues.apache.org/jira/browse/PHOENIX-5842 > Project: Phoenix > Issue Type: Improvement >Reporter: Sandeep Guggilam >Assignee: Sandeep Guggilam >Priority: Major > Labels: quality-improvement > Attachments: PHOENIX-5842.4.x.v1.patch, PHOENIX-5842.4.x.v2.patch > > > Currently we don't have any code coverage tool for Phoenix. This is required > for us to measure the test coverage and helps us in improving the test suite > further till we reach may be 80% coverage > The test coverage results can also be integrated into the Hadoop QA run of > the precommit build such that the reviewers could take a look at the report > and see if the added code doesn't have enough coverage -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (PHOENIX-5842) Code Coverage tool for Phoenix
[ https://issues.apache.org/jira/browse/PHOENIX-5842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sandeep Guggilam updated PHOENIX-5842: -- Attachment: (was: PHOENIX-5842.4.x.v2.patch) > Code Coverage tool for Phoenix > -- > > Key: PHOENIX-5842 > URL: https://issues.apache.org/jira/browse/PHOENIX-5842 > Project: Phoenix > Issue Type: Improvement >Reporter: Sandeep Guggilam >Assignee: Sandeep Guggilam >Priority: Major > Labels: quality-improvement > Attachments: PHOENIX-5842.4.x.v1.patch, PHOENIX-5842.4.x.v2.patch > > > Currently we don't have any code coverage tool for Phoenix. This is required > for us to measure the test coverage and helps us in improving the test suite > further till we reach may be 80% coverage > The test coverage results can also be integrated into the Hadoop QA run of > the precommit build such that the reviewers could take a look at the report > and see if the added code doesn't have enough coverage -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [DISCUSS] Any RM volunteers for a Phoenix 4.16 release?
Great! Thanks for volunteering Xinyi! Looking forward to it. On Tue, May 5, 2020 at 12:14 PM Xinyi Yan wrote: > Hi everyone, > > I think this is a great idea and the right timing to have a new release, > especially we have wonderful new features, a lot of improvements, and bug > fixes in the past few months. > > Yes, I would like to be RM for 4.16 release!!! > > Sincerely, > Xinyi > > On Tue, May 5, 2020 at 12:11 PM Chinmay Kulkarni < > chinmayskulka...@gmail.com> > wrote: > > > Hey everyone, > > > > There's a bunch of indexing bug fixes and new features that have gone in > > after the 4.15.0 release. Some of these need metadata changes mandating > at > > least a minor release. It's also been ~6 months since 4.15.0 was released > > (time flies). > > > > In an effort to have a more consistent release train, I think it's a good > > time to start working on releasing Phoenix 4.16.0! Do we have any > > volunteers for the role of RM? > > > > Thanks, > > Chinmay > > -- > > Chinmay Kulkarni > > > -- Chinmay Kulkarni
Re: [DISCUSS] Any RM volunteers for a Phoenix 4.16 release?
Hi everyone, I think this is a great idea and the right timing to have a new release, especially we have wonderful new features, a lot of improvements, and bug fixes in the past few months. Yes, I would like to be RM for 4.16 release!!! Sincerely, Xinyi On Tue, May 5, 2020 at 12:11 PM Chinmay Kulkarni wrote: > Hey everyone, > > There's a bunch of indexing bug fixes and new features that have gone in > after the 4.15.0 release. Some of these need metadata changes mandating at > least a minor release. It's also been ~6 months since 4.15.0 was released > (time flies). > > In an effort to have a more consistent release train, I think it's a good > time to start working on releasing Phoenix 4.16.0! Do we have any > volunteers for the role of RM? > > Thanks, > Chinmay > -- > Chinmay Kulkarni >
[DISCUSS] Any RM volunteers for a Phoenix 4.16 release?
Hey everyone, There's a bunch of indexing bug fixes and new features that have gone in after the 4.15.0 release. Some of these need metadata changes mandating at least a minor release. It's also been ~6 months since 4.15.0 was released (time flies). In an effort to have a more consistent release train, I think it's a good time to start working on releasing Phoenix 4.16.0! Do we have any volunteers for the role of RM? Thanks, Chinmay -- Chinmay Kulkarni
[jira] [Updated] (PHOENIX-5883) Add HBase 1.6 compatibility module to 4.x branch
[ https://issues.apache.org/jira/browse/PHOENIX-5883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chinmay Kulkarni updated PHOENIX-5883: -- Priority: Major (was: Critical) > Add HBase 1.6 compatibility module to 4.x branch > > > Key: PHOENIX-5883 > URL: https://issues.apache.org/jira/browse/PHOENIX-5883 > Project: Phoenix > Issue Type: Improvement >Affects Versions: 4.15.0, 4.14.3 >Reporter: Chinmay Kulkarni >Priority: Major > Fix For: 4.16.0 > > > We should add a compatibility module for HBase 1.6 similar to the ones added > for HBase 1.3, 1.4 and 1.5 in the 4.x branch. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (PHOENIX-5883) Add HBase 1.6 compatibility module to 4.x branch
Chinmay Kulkarni created PHOENIX-5883: - Summary: Add HBase 1.6 compatibility module to 4.x branch Key: PHOENIX-5883 URL: https://issues.apache.org/jira/browse/PHOENIX-5883 Project: Phoenix Issue Type: Improvement Affects Versions: 4.14.3, 4.15.0 Reporter: Chinmay Kulkarni Fix For: 4.16.0 We should add a compatibility module for HBase 1.6 similar to the ones added for HBase 1.3, 1.4 and 1.5 in the 4.x branch. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (PHOENIX-5842) Code Coverage tool for Phoenix
[ https://issues.apache.org/jira/browse/PHOENIX-5842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sandeep Guggilam updated PHOENIX-5842: -- Attachment: PHOENIX-5842.4.x.v2.patch > Code Coverage tool for Phoenix > -- > > Key: PHOENIX-5842 > URL: https://issues.apache.org/jira/browse/PHOENIX-5842 > Project: Phoenix > Issue Type: Improvement >Reporter: Sandeep Guggilam >Assignee: Sandeep Guggilam >Priority: Major > Labels: quality-improvement > Attachments: PHOENIX-5842.4.x.v1.patch, PHOENIX-5842.4.x.v2.patch > > > Currently we don't have any code coverage tool for Phoenix. This is required > for us to measure the test coverage and helps us in improving the test suite > further till we reach may be 80% coverage > The test coverage results can also be integrated into the Hadoop QA run of > the precommit build such that the reviewers could take a look at the report > and see if the added code doesn't have enough coverage -- This message was sent by Atlassian Jira (v8.3.4#803005)
