Re: 5.0.0-HBase-2.0 Phoenix client release

2020-03-05 Thread Istvan Toth 
It looks like a mistake.
*mvn install* does create the artifacts locally, so something must have
gone wrong during the release process.

I guess we ought to fix this, but I'm not even sure if it is possible to
amend the public repos after release.

Istvan

On Wed, Mar 4, 2020 at 10:57 PM Sandeep G  wrote:

> Hi
> We have released Apache Phoenix 5.0.0-HBase-2.0 bits as per our downloads
> page here: https://phoenix.apache.org/download.html
>
> However when I try to do a dependency download of phoenix-client with the
> same version, I get an error. On looking further , I see that the
> phoenix-client jar for 5.0.0 is not present under
>
> https://repository.apache.org/content/repositories/releases/org/apache/phoenix/phoenix-client/
>
> However the phoenix-core for 5.0.0-HBase-2.0 is present under
>
> https://repository.apache.org/content/repositories/releases/org/apache/phoenix/phoenix-core/
>
> Can someone help me with why the phoenix-client module is not released for
> 5.0.0-HBase-2.0 ?
>
> Thanks
> --Sandeep
>


-- 
*István Tóth* | Sr. Software Engineer
st...@cloudera.com 
[image: Cloudera] 
[image: Cloudera on Twitter]  [image:
Cloudera on Facebook]  [image: Cloudera
on LinkedIn] 

--

[jira] [Updated] (PHOENIX-5607) Client-server backward compatibility tests

2020-03-05 Thread Sandeep Guggilam (Jira) 


 [ 
https://issues.apache.org/jira/browse/PHOENIX-5607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sandeep Guggilam updated PHOENIX-5607:
--
Attachment: (was: PHOENIX-5607.master.v1.patch)

> Client-server backward compatibility tests 
> ---
>
> Key: PHOENIX-5607
> URL: https://issues.apache.org/jira/browse/PHOENIX-5607
> Project: Phoenix
>  Issue Type: Test
>Affects Versions: 4.15.0
>Reporter: Lars Hofhansl
>Assignee: Sandeep Guggilam
>Priority: Blocker
>  Labels: phoenix-hardening
> Fix For: 4.16.0
>
> Attachments: PHOENIX-5607.4.x-HBase-1.3.v1.patch, 
> PHOENIX-5607.4.x-HBase-1.3.v2.patch, PHOENIX-5607.4.x-HBase-1.3.v3.patch, 
> PHOENIX-5607.4.x-HBase-1.3.v4.patch, PHOENIX-5607.4.x-HBase-1.3.v5.patch, 
> PHOENIX-5607.master.v1.patch
>
>  Time Spent: 2h
>  Remaining Estimate: 0h
>
> Filing this as a blocker for 4.16.0.
> As we've seen with the various failed attempts to release 4.15.0 Phoenix' 
> backwards compatibility story is weak, and lacks tests - in fact there're no 
> tests.
> We should not allow to ship 4.16.0 without improving that and without tests.
> [~ckulkarni], [~gjacoby] , FYI, what we discussed.



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

[jira] [Updated] (PHOENIX-5607) Client-server backward compatibility tests

2020-03-05 Thread Sandeep Guggilam (Jira) 


 [ 
https://issues.apache.org/jira/browse/PHOENIX-5607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sandeep Guggilam updated PHOENIX-5607:
--
Attachment: PHOENIX-5607.master.v1.patch

> Client-server backward compatibility tests 
> ---
>
> Key: PHOENIX-5607
> URL: https://issues.apache.org/jira/browse/PHOENIX-5607
> Project: Phoenix
>  Issue Type: Test
>Affects Versions: 4.15.0
>Reporter: Lars Hofhansl
>Assignee: Sandeep Guggilam
>Priority: Blocker
>  Labels: phoenix-hardening
> Fix For: 4.16.0
>
> Attachments: PHOENIX-5607.4.x-HBase-1.3.v1.patch, 
> PHOENIX-5607.4.x-HBase-1.3.v2.patch, PHOENIX-5607.4.x-HBase-1.3.v3.patch, 
> PHOENIX-5607.4.x-HBase-1.3.v4.patch, PHOENIX-5607.4.x-HBase-1.3.v5.patch, 
> PHOENIX-5607.master.v1.patch
>
>  Time Spent: 2h
>  Remaining Estimate: 0h
>
> Filing this as a blocker for 4.16.0.
> As we've seen with the various failed attempts to release 4.15.0 Phoenix' 
> backwards compatibility story is weak, and lacks tests - in fact there're no 
> tests.
> We should not allow to ship 4.16.0 without improving that and without tests.
> [~ckulkarni], [~gjacoby] , FYI, what we discussed.



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

[jira] [Updated] (PHOENIX-5317) Upserting rows into child views with pk fails when the base view has an index on it.

2020-03-05 Thread Sandeep Guggilam (Jira) 


 [ 
https://issues.apache.org/jira/browse/PHOENIX-5317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sandeep Guggilam updated PHOENIX-5317:
--
Attachment: (was: PHOENIX-5317.4.x-HBase-1.3.v2.patch)

> Upserting rows into child views with pk fails when the base view has an index 
> on it.
> 
>
> Key: PHOENIX-5317
> URL: https://issues.apache.org/jira/browse/PHOENIX-5317
> Project: Phoenix
>  Issue Type: Sub-task
>Affects Versions: 4.13.0, 4.14.1
>Reporter: Jacob Isaac
>Assignee: Sandeep Guggilam
>Priority: Major
> Attachments: PHOENIX-5137-TestFailure.txt, 
> PHOENIX-5317.4.x-HBase-1.3.v1.patch, PHOENIX-5317.4.x-HBase-1.3.v2.patch
>
>
> Steps to reproduce - 
> 1 Create Base Table, Base/Global View and Index using non tenanted connection.
> CREATE TABLE IF NOT EXISTS TEST.BASETABLE (
> TENANT_ID CHAR(15) NOT NULL, 
> KEY_PREFIX CHAR(3) NOT NULL, 
> CREATED_DATE DATE,
> CREATED_BY CHAR(15),
> SYSTEM_MODSTAMP DATE
> CONSTRAINT PK PRIMARY KEY (
> TENANT_ID, 
> KEY_PREFIX 
> )
> ) VERSIONS=1, MULTI_TENANT=true, IMMUTABLE_ROWS=TRUE, REPLICATION_SCOPE=1;
> CREATE VIEW IF NOT EXISTS TEST.MY_GLOBAL_VIEW  (
> TEXT1 VARCHAR NOT NULL,
> INT1 BIGINT NOT NULL,
> DOUBLE1 DECIMAL(12, 3),
> IS_BOOLEAN BOOLEAN,
> RELATIONSHIP_ID CHAR(15),
> TEXT_READ_ONLY VARCHAR,
> DATE_TIME1 DATE,
> JSON1 VARCHAR,
> IP_START_ADDRESS VARCHAR
> CONSTRAINT PKVIEW PRIMARY KEY
> (
> TEXT1, INT1
> )
> )
> AS SELECT * FROM TEST.BASETABLE WHERE KEY_PREFIX = '0CY';
> CREATE INDEX IF NOT EXISTS TEST_MY_GLOBAL_VIEW_SEC_INDEX
> ON TEST.MY_GLOBAL_VIEW (TEXT1, INT1)
> INCLUDE (CREATED_BY, RELATIONSHIP_ID, JSON1, DOUBLE1, IS_BOOLEAN, 
> IP_START_ADDRESS, CREATED_DATE, SYSTEM_MODSTAMP, TEXT_READ_ONLY);
> 2. Create child view using an tenant-owned connection
> CREATE VIEW IF NOT EXISTS TEST."z01" (COL1 VARCHAR, COL2 VARCHAR, COL3 
> VARCHAR, COL4 VARCHAR CONSTRAINT PK PRIMARY KEY (COL1, COL2, COL3, COL4)) AS 
> SELECT * FROM TEST.MY_GLOBAL_VIEW; 
> 3. Upsert into child view
> UPSERT INTO TEST."z01" (DATE_TIME1, INT1, TEXT1, COL1, COL2, COL3, COL4) 
> VALUES (TO_DATE('2017-10-16 22:00:00', '-MM-dd HH:mm:ss'), 10, 'z', 
> '8', 'z', 'z', 'z');
> Following exception is thrown -
> 0: jdbc:phoenix:localhost> UPSERT INTO TEST."z01" (DATE_TIME1, INT1, TEXT1, 
> COL1, COL2, COL3, COL4) VALUES (TO_DATE('2017-10-16 22:00:00', '-MM-dd 
> HH:mm:ss'), 10, 'z', '8', 'z', 'z', 'z');
> java.lang.IllegalArgumentException
>   at 
> com.google.common.base.Preconditions.checkArgument(Preconditions.java:76)
>   at 
> com.google.common.collect.Lists.computeArrayListCapacity(Lists.java:105)
>   at 
> com.google.common.collect.Lists.newArrayListWithExpectedSize(Lists.java:195)
>   at 
> org.apache.phoenix.index.IndexMaintainer.(IndexMaintainer.java:424)
>   at 
> org.apache.phoenix.index.IndexMaintainer.create(IndexMaintainer.java:143)
>   at 
> org.apache.phoenix.schema.PTableImpl.getIndexMaintainer(PTableImpl.java:1176)
>   at 
> org.apache.phoenix.util.IndexUtil.generateIndexData(IndexUtil.java:303)
>   at 
> org.apache.phoenix.execute.MutationState$1.next(MutationState.java:519)
>   at 
> org.apache.phoenix.execute.MutationState$1.next(MutationState.java:501)
>   at org.apache.phoenix.execute.MutationState.send(MutationState.java:941)
>   at 
> org.apache.phoenix.execute.MutationState.send(MutationState.java:1387)
>   at 
> org.apache.phoenix.execute.MutationState.commit(MutationState.java:1228)
>   at 
> org.apache.phoenix.jdbc.PhoenixConnection$3.call(PhoenixConnection.java:666)
>   at 
> org.apache.phoenix.jdbc.PhoenixConnection$3.call(PhoenixConnection.java:662)
>   at org.apache.phoenix.call.CallRunner.run(CallRunner.java:53)
>   at 
> org.apache.phoenix.jdbc.PhoenixConnection.commit(PhoenixConnection.java:662)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:399)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:379)
>   at org.apache.phoenix.call.CallRunner.run(CallRunner.java:53)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement.executeMutation(PhoenixStatement.java:378)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement.executeMutation(PhoenixStatement.java:366)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement.execute(PhoenixStatement.java:1775)
>   at sqlline.Commands.execute(Commands.java:822)
>   at sqlline.Commands.sql(Commands.java:732)
>   at sqlline.SqlLine.dispatch(SqlLine.java:807)
>   at sqlline.SqlLine.begin(SqlLine.java:681)
>   at sqlline.SqlLine.start(SqlLine.java:398)
>   at sqlline.SqlLine.main(SqlLine.java:292)



--
This message

[jira] [Updated] (PHOENIX-5317) Upserting rows into child views with pk fails when the base view has an index on it.

2020-03-05 Thread Sandeep Guggilam (Jira) 


 [ 
https://issues.apache.org/jira/browse/PHOENIX-5317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sandeep Guggilam updated PHOENIX-5317:
--
Attachment: PHOENIX-5317.4.x-HBase-1.3.v2.patch

> Upserting rows into child views with pk fails when the base view has an index 
> on it.
> 
>
> Key: PHOENIX-5317
> URL: https://issues.apache.org/jira/browse/PHOENIX-5317
> Project: Phoenix
>  Issue Type: Sub-task
>Affects Versions: 4.13.0, 4.14.1
>Reporter: Jacob Isaac
>Assignee: Sandeep Guggilam
>Priority: Major
> Attachments: PHOENIX-5137-TestFailure.txt, 
> PHOENIX-5317.4.x-HBase-1.3.v1.patch, PHOENIX-5317.4.x-HBase-1.3.v2.patch
>
>
> Steps to reproduce - 
> 1 Create Base Table, Base/Global View and Index using non tenanted connection.
> CREATE TABLE IF NOT EXISTS TEST.BASETABLE (
> TENANT_ID CHAR(15) NOT NULL, 
> KEY_PREFIX CHAR(3) NOT NULL, 
> CREATED_DATE DATE,
> CREATED_BY CHAR(15),
> SYSTEM_MODSTAMP DATE
> CONSTRAINT PK PRIMARY KEY (
> TENANT_ID, 
> KEY_PREFIX 
> )
> ) VERSIONS=1, MULTI_TENANT=true, IMMUTABLE_ROWS=TRUE, REPLICATION_SCOPE=1;
> CREATE VIEW IF NOT EXISTS TEST.MY_GLOBAL_VIEW  (
> TEXT1 VARCHAR NOT NULL,
> INT1 BIGINT NOT NULL,
> DOUBLE1 DECIMAL(12, 3),
> IS_BOOLEAN BOOLEAN,
> RELATIONSHIP_ID CHAR(15),
> TEXT_READ_ONLY VARCHAR,
> DATE_TIME1 DATE,
> JSON1 VARCHAR,
> IP_START_ADDRESS VARCHAR
> CONSTRAINT PKVIEW PRIMARY KEY
> (
> TEXT1, INT1
> )
> )
> AS SELECT * FROM TEST.BASETABLE WHERE KEY_PREFIX = '0CY';
> CREATE INDEX IF NOT EXISTS TEST_MY_GLOBAL_VIEW_SEC_INDEX
> ON TEST.MY_GLOBAL_VIEW (TEXT1, INT1)
> INCLUDE (CREATED_BY, RELATIONSHIP_ID, JSON1, DOUBLE1, IS_BOOLEAN, 
> IP_START_ADDRESS, CREATED_DATE, SYSTEM_MODSTAMP, TEXT_READ_ONLY);
> 2. Create child view using an tenant-owned connection
> CREATE VIEW IF NOT EXISTS TEST."z01" (COL1 VARCHAR, COL2 VARCHAR, COL3 
> VARCHAR, COL4 VARCHAR CONSTRAINT PK PRIMARY KEY (COL1, COL2, COL3, COL4)) AS 
> SELECT * FROM TEST.MY_GLOBAL_VIEW; 
> 3. Upsert into child view
> UPSERT INTO TEST."z01" (DATE_TIME1, INT1, TEXT1, COL1, COL2, COL3, COL4) 
> VALUES (TO_DATE('2017-10-16 22:00:00', '-MM-dd HH:mm:ss'), 10, 'z', 
> '8', 'z', 'z', 'z');
> Following exception is thrown -
> 0: jdbc:phoenix:localhost> UPSERT INTO TEST."z01" (DATE_TIME1, INT1, TEXT1, 
> COL1, COL2, COL3, COL4) VALUES (TO_DATE('2017-10-16 22:00:00', '-MM-dd 
> HH:mm:ss'), 10, 'z', '8', 'z', 'z', 'z');
> java.lang.IllegalArgumentException
>   at 
> com.google.common.base.Preconditions.checkArgument(Preconditions.java:76)
>   at 
> com.google.common.collect.Lists.computeArrayListCapacity(Lists.java:105)
>   at 
> com.google.common.collect.Lists.newArrayListWithExpectedSize(Lists.java:195)
>   at 
> org.apache.phoenix.index.IndexMaintainer.(IndexMaintainer.java:424)
>   at 
> org.apache.phoenix.index.IndexMaintainer.create(IndexMaintainer.java:143)
>   at 
> org.apache.phoenix.schema.PTableImpl.getIndexMaintainer(PTableImpl.java:1176)
>   at 
> org.apache.phoenix.util.IndexUtil.generateIndexData(IndexUtil.java:303)
>   at 
> org.apache.phoenix.execute.MutationState$1.next(MutationState.java:519)
>   at 
> org.apache.phoenix.execute.MutationState$1.next(MutationState.java:501)
>   at org.apache.phoenix.execute.MutationState.send(MutationState.java:941)
>   at 
> org.apache.phoenix.execute.MutationState.send(MutationState.java:1387)
>   at 
> org.apache.phoenix.execute.MutationState.commit(MutationState.java:1228)
>   at 
> org.apache.phoenix.jdbc.PhoenixConnection$3.call(PhoenixConnection.java:666)
>   at 
> org.apache.phoenix.jdbc.PhoenixConnection$3.call(PhoenixConnection.java:662)
>   at org.apache.phoenix.call.CallRunner.run(CallRunner.java:53)
>   at 
> org.apache.phoenix.jdbc.PhoenixConnection.commit(PhoenixConnection.java:662)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:399)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:379)
>   at org.apache.phoenix.call.CallRunner.run(CallRunner.java:53)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement.executeMutation(PhoenixStatement.java:378)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement.executeMutation(PhoenixStatement.java:366)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement.execute(PhoenixStatement.java:1775)
>   at sqlline.Commands.execute(Commands.java:822)
>   at sqlline.Commands.sql(Commands.java:732)
>   at sqlline.SqlLine.dispatch(SqlLine.java:807)
>   at sqlline.SqlLine.begin(SqlLine.java:681)
>   at sqlline.SqlLine.start(SqlLine.java:398)
>   at sqlline.SqlLine.main(SqlLine.java:292)



--
This message was sent by

[jira] [Updated] (PHOENIX-5607) Client-server backward compatibility tests

2020-03-05 Thread Sandeep Guggilam (Jira) 


 [ 
https://issues.apache.org/jira/browse/PHOENIX-5607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sandeep Guggilam updated PHOENIX-5607:
--
Attachment: PHOENIX-5607.master.v1.patch

> Client-server backward compatibility tests 
> ---
>
> Key: PHOENIX-5607
> URL: https://issues.apache.org/jira/browse/PHOENIX-5607
> Project: Phoenix
>  Issue Type: Test
>Affects Versions: 4.15.0
>Reporter: Lars Hofhansl
>Assignee: Sandeep Guggilam
>Priority: Blocker
>  Labels: phoenix-hardening
> Fix For: 4.16.0
>
> Attachments: PHOENIX-5607.4.x-HBase-1.3.v1.patch, 
> PHOENIX-5607.4.x-HBase-1.3.v2.patch, PHOENIX-5607.4.x-HBase-1.3.v3.patch, 
> PHOENIX-5607.4.x-HBase-1.3.v4.patch, PHOENIX-5607.4.x-HBase-1.3.v5.patch, 
> PHOENIX-5607.master.v1.patch
>
>  Time Spent: 2h
>  Remaining Estimate: 0h
>
> Filing this as a blocker for 4.16.0.
> As we've seen with the various failed attempts to release 4.15.0 Phoenix' 
> backwards compatibility story is weak, and lacks tests - in fact there're no 
> tests.
> We should not allow to ship 4.16.0 without improving that and without tests.
> [~ckulkarni], [~gjacoby] , FYI, what we discussed.



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

[jira] [Updated] (PHOENIX-4845) Support using Row Value Constructors in OFFSET clause for paging in tables where the sort order of PK columns varies

2020-03-05 Thread Daniel Wong (Jira) 


 [ 
https://issues.apache.org/jira/browse/PHOENIX-4845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Daniel Wong updated PHOENIX-4845:
-
Attachment: PHOENIX-4845-4.x-HBase-1.3.v3.patch

> Support using Row Value Constructors in OFFSET clause for paging in tables 
> where the sort order of PK columns varies
> 
>
> Key: PHOENIX-4845
> URL: https://issues.apache.org/jira/browse/PHOENIX-4845
> Project: Phoenix
>  Issue Type: New Feature
>Reporter: Thomas D'Silva
>Assignee: Daniel Wong
>Priority: Major
>  Labels: DESC, SFDC
> Attachments: PHOENIX-4845-4.x-HBase-1.3.patch, 
> PHOENIX-4845-4.x-HBase-1.3.v2.patch, PHOENIX-4845-4.x-HBase-1.3.v3.patch, 
> PHOENIX-4845.patch, PHOENIX-offset.txt
>
>  Time Spent: 16h 10m
>  Remaining Estimate: 0h
>
> RVCs along with the LIMIT clause are useful for efficiently paging through 
> rows (see [http://phoenix.apache.org/paged.html]). This works well if the pk 
> columns are sorted ascending, we can always use the > operator to query for 
> the next batch of row.
> However if the PK of a table is (A  DESC, B DESC) we cannot use the following 
> query to page through the data
> {code:java}
> SELECT * FROM TABLE WHERE (A, B) > (?, ?) ORDER BY A DESC, B DESC LIMIT 20
> {code}
> Since the rows are sorted by A desc and then by B descending we need change 
> the comparison order
> {code:java}
> SELECT * FROM TABLE WHERE (A, B) < (?, ?) ORDER BY A DESC, B DESC LIMIT 20
> {code}
> If the PK of a table contains columns with mixed sort order for eg (A  DESC, 
> B) then we cannot use RVC to page through data.
> If we supported using RVCs in the offset clause we could use the offset to 
> set the start row of the scan. Clients would not have to have logic to 
> determine the comparison operator. This would also support paging through 
> data for tables where the PK columns are sorted in mixed order.
> {code:java}
> SELECT * FROM TABLE ORDER BY A DESC, B LIMIT 20 OFFSET (?,?)
> {code}
> We would only allow using the offset if the rows are ordered by the sort 
> order of the PK columns of and Index or Primary Table.
> Note that there is some care is needed in the use of OFFSET with indexes.  If 
> the OFFSET is coercible to multiple indexes/base table it could mean very 
> different positions based on key.  To Handle This the INDEX hint needs to be 
> used to specify an index offset for safety.



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

[jira] [Updated] (PHOENIX-4845) Support using Row Value Constructors in OFFSET clause for paging in tables where the sort order of PK columns varies

2020-03-05 Thread Daniel Wong (Jira) 


 [ 
https://issues.apache.org/jira/browse/PHOENIX-4845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Daniel Wong updated PHOENIX-4845:
-
Attachment: PHOENIX-4845.patch

> Support using Row Value Constructors in OFFSET clause for paging in tables 
> where the sort order of PK columns varies
> 
>
> Key: PHOENIX-4845
> URL: https://issues.apache.org/jira/browse/PHOENIX-4845
> Project: Phoenix
>  Issue Type: New Feature
>Reporter: Thomas D'Silva
>Assignee: Daniel Wong
>Priority: Major
>  Labels: DESC, SFDC
> Attachments: PHOENIX-4845-4.x-HBase-1.3.patch, 
> PHOENIX-4845-4.x-HBase-1.3.v2.patch, PHOENIX-4845.patch, PHOENIX-offset.txt
>
>  Time Spent: 16h
>  Remaining Estimate: 0h
>
> RVCs along with the LIMIT clause are useful for efficiently paging through 
> rows (see [http://phoenix.apache.org/paged.html]). This works well if the pk 
> columns are sorted ascending, we can always use the > operator to query for 
> the next batch of row.
> However if the PK of a table is (A  DESC, B DESC) we cannot use the following 
> query to page through the data
> {code:java}
> SELECT * FROM TABLE WHERE (A, B) > (?, ?) ORDER BY A DESC, B DESC LIMIT 20
> {code}
> Since the rows are sorted by A desc and then by B descending we need change 
> the comparison order
> {code:java}
> SELECT * FROM TABLE WHERE (A, B) < (?, ?) ORDER BY A DESC, B DESC LIMIT 20
> {code}
> If the PK of a table contains columns with mixed sort order for eg (A  DESC, 
> B) then we cannot use RVC to page through data.
> If we supported using RVCs in the offset clause we could use the offset to 
> set the start row of the scan. Clients would not have to have logic to 
> determine the comparison operator. This would also support paging through 
> data for tables where the PK columns are sorted in mixed order.
> {code:java}
> SELECT * FROM TABLE ORDER BY A DESC, B LIMIT 20 OFFSET (?,?)
> {code}
> We would only allow using the offset if the rows are ordered by the sort 
> order of the PK columns of and Index or Primary Table.
> Note that there is some care is needed in the use of OFFSET with indexes.  If 
> the OFFSET is coercible to multiple indexes/base table it could mean very 
> different positions based on key.  To Handle This the INDEX hint needs to be 
> used to specify an index offset for safety.



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

[jira] [Updated] (PHOENIX-4845) Support using Row Value Constructors in OFFSET clause for paging in tables where the sort order of PK columns varies

2020-03-05 Thread Daniel Wong (Jira) 


 [ 
https://issues.apache.org/jira/browse/PHOENIX-4845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Daniel Wong updated PHOENIX-4845:
-
Attachment: PHOENIX-4845-4.x-HBase-1.3.v2.patch

> Support using Row Value Constructors in OFFSET clause for paging in tables 
> where the sort order of PK columns varies
> 
>
> Key: PHOENIX-4845
> URL: https://issues.apache.org/jira/browse/PHOENIX-4845
> Project: Phoenix
>  Issue Type: New Feature
>Reporter: Thomas D'Silva
>Assignee: Daniel Wong
>Priority: Major
>  Labels: DESC, SFDC
> Attachments: PHOENIX-4845-4.x-HBase-1.3.patch, 
> PHOENIX-4845-4.x-HBase-1.3.v2.patch, PHOENIX-offset.txt
>
>  Time Spent: 16h
>  Remaining Estimate: 0h
>
> RVCs along with the LIMIT clause are useful for efficiently paging through 
> rows (see [http://phoenix.apache.org/paged.html]). This works well if the pk 
> columns are sorted ascending, we can always use the > operator to query for 
> the next batch of row.
> However if the PK of a table is (A  DESC, B DESC) we cannot use the following 
> query to page through the data
> {code:java}
> SELECT * FROM TABLE WHERE (A, B) > (?, ?) ORDER BY A DESC, B DESC LIMIT 20
> {code}
> Since the rows are sorted by A desc and then by B descending we need change 
> the comparison order
> {code:java}
> SELECT * FROM TABLE WHERE (A, B) < (?, ?) ORDER BY A DESC, B DESC LIMIT 20
> {code}
> If the PK of a table contains columns with mixed sort order for eg (A  DESC, 
> B) then we cannot use RVC to page through data.
> If we supported using RVCs in the offset clause we could use the offset to 
> set the start row of the scan. Clients would not have to have logic to 
> determine the comparison operator. This would also support paging through 
> data for tables where the PK columns are sorted in mixed order.
> {code:java}
> SELECT * FROM TABLE ORDER BY A DESC, B LIMIT 20 OFFSET (?,?)
> {code}
> We would only allow using the offset if the rows are ordered by the sort 
> order of the PK columns of and Index or Primary Table.
> Note that there is some care is needed in the use of OFFSET with indexes.  If 
> the OFFSET is coercible to multiple indexes/base table it could mean very 
> different positions based on key.  To Handle This the INDEX hint needs to be 
> used to specify an index offset for safety.



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

[jira] [Updated] (PHOENIX-5317) Upserting rows into child views with pk fails when the base view has an index on it.

2020-03-05 Thread Sandeep Guggilam (Jira) 


 [ 
https://issues.apache.org/jira/browse/PHOENIX-5317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sandeep Guggilam updated PHOENIX-5317:
--
Attachment: PHOENIX-5317.4.x-HBase-1.3.v2.patch

> Upserting rows into child views with pk fails when the base view has an index 
> on it.
> 
>
> Key: PHOENIX-5317
> URL: https://issues.apache.org/jira/browse/PHOENIX-5317
> Project: Phoenix
>  Issue Type: Sub-task
>Affects Versions: 4.13.0, 4.14.1
>Reporter: Jacob Isaac
>Assignee: Sandeep Guggilam
>Priority: Major
> Attachments: PHOENIX-5137-TestFailure.txt, 
> PHOENIX-5317.4.x-HBase-1.3.v1.patch, PHOENIX-5317.4.x-HBase-1.3.v2.patch
>
>
> Steps to reproduce - 
> 1 Create Base Table, Base/Global View and Index using non tenanted connection.
> CREATE TABLE IF NOT EXISTS TEST.BASETABLE (
> TENANT_ID CHAR(15) NOT NULL, 
> KEY_PREFIX CHAR(3) NOT NULL, 
> CREATED_DATE DATE,
> CREATED_BY CHAR(15),
> SYSTEM_MODSTAMP DATE
> CONSTRAINT PK PRIMARY KEY (
> TENANT_ID, 
> KEY_PREFIX 
> )
> ) VERSIONS=1, MULTI_TENANT=true, IMMUTABLE_ROWS=TRUE, REPLICATION_SCOPE=1;
> CREATE VIEW IF NOT EXISTS TEST.MY_GLOBAL_VIEW  (
> TEXT1 VARCHAR NOT NULL,
> INT1 BIGINT NOT NULL,
> DOUBLE1 DECIMAL(12, 3),
> IS_BOOLEAN BOOLEAN,
> RELATIONSHIP_ID CHAR(15),
> TEXT_READ_ONLY VARCHAR,
> DATE_TIME1 DATE,
> JSON1 VARCHAR,
> IP_START_ADDRESS VARCHAR
> CONSTRAINT PKVIEW PRIMARY KEY
> (
> TEXT1, INT1
> )
> )
> AS SELECT * FROM TEST.BASETABLE WHERE KEY_PREFIX = '0CY';
> CREATE INDEX IF NOT EXISTS TEST_MY_GLOBAL_VIEW_SEC_INDEX
> ON TEST.MY_GLOBAL_VIEW (TEXT1, INT1)
> INCLUDE (CREATED_BY, RELATIONSHIP_ID, JSON1, DOUBLE1, IS_BOOLEAN, 
> IP_START_ADDRESS, CREATED_DATE, SYSTEM_MODSTAMP, TEXT_READ_ONLY);
> 2. Create child view using an tenant-owned connection
> CREATE VIEW IF NOT EXISTS TEST."z01" (COL1 VARCHAR, COL2 VARCHAR, COL3 
> VARCHAR, COL4 VARCHAR CONSTRAINT PK PRIMARY KEY (COL1, COL2, COL3, COL4)) AS 
> SELECT * FROM TEST.MY_GLOBAL_VIEW; 
> 3. Upsert into child view
> UPSERT INTO TEST."z01" (DATE_TIME1, INT1, TEXT1, COL1, COL2, COL3, COL4) 
> VALUES (TO_DATE('2017-10-16 22:00:00', '-MM-dd HH:mm:ss'), 10, 'z', 
> '8', 'z', 'z', 'z');
> Following exception is thrown -
> 0: jdbc:phoenix:localhost> UPSERT INTO TEST."z01" (DATE_TIME1, INT1, TEXT1, 
> COL1, COL2, COL3, COL4) VALUES (TO_DATE('2017-10-16 22:00:00', '-MM-dd 
> HH:mm:ss'), 10, 'z', '8', 'z', 'z', 'z');
> java.lang.IllegalArgumentException
>   at 
> com.google.common.base.Preconditions.checkArgument(Preconditions.java:76)
>   at 
> com.google.common.collect.Lists.computeArrayListCapacity(Lists.java:105)
>   at 
> com.google.common.collect.Lists.newArrayListWithExpectedSize(Lists.java:195)
>   at 
> org.apache.phoenix.index.IndexMaintainer.(IndexMaintainer.java:424)
>   at 
> org.apache.phoenix.index.IndexMaintainer.create(IndexMaintainer.java:143)
>   at 
> org.apache.phoenix.schema.PTableImpl.getIndexMaintainer(PTableImpl.java:1176)
>   at 
> org.apache.phoenix.util.IndexUtil.generateIndexData(IndexUtil.java:303)
>   at 
> org.apache.phoenix.execute.MutationState$1.next(MutationState.java:519)
>   at 
> org.apache.phoenix.execute.MutationState$1.next(MutationState.java:501)
>   at org.apache.phoenix.execute.MutationState.send(MutationState.java:941)
>   at 
> org.apache.phoenix.execute.MutationState.send(MutationState.java:1387)
>   at 
> org.apache.phoenix.execute.MutationState.commit(MutationState.java:1228)
>   at 
> org.apache.phoenix.jdbc.PhoenixConnection$3.call(PhoenixConnection.java:666)
>   at 
> org.apache.phoenix.jdbc.PhoenixConnection$3.call(PhoenixConnection.java:662)
>   at org.apache.phoenix.call.CallRunner.run(CallRunner.java:53)
>   at 
> org.apache.phoenix.jdbc.PhoenixConnection.commit(PhoenixConnection.java:662)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:399)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:379)
>   at org.apache.phoenix.call.CallRunner.run(CallRunner.java:53)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement.executeMutation(PhoenixStatement.java:378)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement.executeMutation(PhoenixStatement.java:366)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement.execute(PhoenixStatement.java:1775)
>   at sqlline.Commands.execute(Commands.java:822)
>   at sqlline.Commands.sql(Commands.java:732)
>   at sqlline.SqlLine.dispatch(SqlLine.java:807)
>   at sqlline.SqlLine.begin(SqlLine.java:681)
>   at sqlline.SqlLine.start(SqlLine.java:398)
>   at sqlline.SqlLine.main(SqlLine.java:292)



--
This message was sent by

[jira] [Updated] (PHOENIX-5317) Upserting rows into child views with pk fails when the base view has an index on it.

2020-03-05 Thread Sandeep Guggilam (Jira) 


 [ 
https://issues.apache.org/jira/browse/PHOENIX-5317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sandeep Guggilam updated PHOENIX-5317:
--
Attachment: (was: PHOENIX-5317.4.x-HBase-1.3.v1.patch)

> Upserting rows into child views with pk fails when the base view has an index 
> on it.
> 
>
> Key: PHOENIX-5317
> URL: https://issues.apache.org/jira/browse/PHOENIX-5317
> Project: Phoenix
>  Issue Type: Sub-task
>Affects Versions: 4.13.0, 4.14.1
>Reporter: Jacob Isaac
>Assignee: Sandeep Guggilam
>Priority: Major
> Attachments: PHOENIX-5137-TestFailure.txt, 
> PHOENIX-5317.4.x-HBase-1.3.v1.patch, PHOENIX-5317.4.x-HBase-1.3.v2.patch
>
>
> Steps to reproduce - 
> 1 Create Base Table, Base/Global View and Index using non tenanted connection.
> CREATE TABLE IF NOT EXISTS TEST.BASETABLE (
> TENANT_ID CHAR(15) NOT NULL, 
> KEY_PREFIX CHAR(3) NOT NULL, 
> CREATED_DATE DATE,
> CREATED_BY CHAR(15),
> SYSTEM_MODSTAMP DATE
> CONSTRAINT PK PRIMARY KEY (
> TENANT_ID, 
> KEY_PREFIX 
> )
> ) VERSIONS=1, MULTI_TENANT=true, IMMUTABLE_ROWS=TRUE, REPLICATION_SCOPE=1;
> CREATE VIEW IF NOT EXISTS TEST.MY_GLOBAL_VIEW  (
> TEXT1 VARCHAR NOT NULL,
> INT1 BIGINT NOT NULL,
> DOUBLE1 DECIMAL(12, 3),
> IS_BOOLEAN BOOLEAN,
> RELATIONSHIP_ID CHAR(15),
> TEXT_READ_ONLY VARCHAR,
> DATE_TIME1 DATE,
> JSON1 VARCHAR,
> IP_START_ADDRESS VARCHAR
> CONSTRAINT PKVIEW PRIMARY KEY
> (
> TEXT1, INT1
> )
> )
> AS SELECT * FROM TEST.BASETABLE WHERE KEY_PREFIX = '0CY';
> CREATE INDEX IF NOT EXISTS TEST_MY_GLOBAL_VIEW_SEC_INDEX
> ON TEST.MY_GLOBAL_VIEW (TEXT1, INT1)
> INCLUDE (CREATED_BY, RELATIONSHIP_ID, JSON1, DOUBLE1, IS_BOOLEAN, 
> IP_START_ADDRESS, CREATED_DATE, SYSTEM_MODSTAMP, TEXT_READ_ONLY);
> 2. Create child view using an tenant-owned connection
> CREATE VIEW IF NOT EXISTS TEST."z01" (COL1 VARCHAR, COL2 VARCHAR, COL3 
> VARCHAR, COL4 VARCHAR CONSTRAINT PK PRIMARY KEY (COL1, COL2, COL3, COL4)) AS 
> SELECT * FROM TEST.MY_GLOBAL_VIEW; 
> 3. Upsert into child view
> UPSERT INTO TEST."z01" (DATE_TIME1, INT1, TEXT1, COL1, COL2, COL3, COL4) 
> VALUES (TO_DATE('2017-10-16 22:00:00', '-MM-dd HH:mm:ss'), 10, 'z', 
> '8', 'z', 'z', 'z');
> Following exception is thrown -
> 0: jdbc:phoenix:localhost> UPSERT INTO TEST."z01" (DATE_TIME1, INT1, TEXT1, 
> COL1, COL2, COL3, COL4) VALUES (TO_DATE('2017-10-16 22:00:00', '-MM-dd 
> HH:mm:ss'), 10, 'z', '8', 'z', 'z', 'z');
> java.lang.IllegalArgumentException
>   at 
> com.google.common.base.Preconditions.checkArgument(Preconditions.java:76)
>   at 
> com.google.common.collect.Lists.computeArrayListCapacity(Lists.java:105)
>   at 
> com.google.common.collect.Lists.newArrayListWithExpectedSize(Lists.java:195)
>   at 
> org.apache.phoenix.index.IndexMaintainer.(IndexMaintainer.java:424)
>   at 
> org.apache.phoenix.index.IndexMaintainer.create(IndexMaintainer.java:143)
>   at 
> org.apache.phoenix.schema.PTableImpl.getIndexMaintainer(PTableImpl.java:1176)
>   at 
> org.apache.phoenix.util.IndexUtil.generateIndexData(IndexUtil.java:303)
>   at 
> org.apache.phoenix.execute.MutationState$1.next(MutationState.java:519)
>   at 
> org.apache.phoenix.execute.MutationState$1.next(MutationState.java:501)
>   at org.apache.phoenix.execute.MutationState.send(MutationState.java:941)
>   at 
> org.apache.phoenix.execute.MutationState.send(MutationState.java:1387)
>   at 
> org.apache.phoenix.execute.MutationState.commit(MutationState.java:1228)
>   at 
> org.apache.phoenix.jdbc.PhoenixConnection$3.call(PhoenixConnection.java:666)
>   at 
> org.apache.phoenix.jdbc.PhoenixConnection$3.call(PhoenixConnection.java:662)
>   at org.apache.phoenix.call.CallRunner.run(CallRunner.java:53)
>   at 
> org.apache.phoenix.jdbc.PhoenixConnection.commit(PhoenixConnection.java:662)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:399)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:379)
>   at org.apache.phoenix.call.CallRunner.run(CallRunner.java:53)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement.executeMutation(PhoenixStatement.java:378)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement.executeMutation(PhoenixStatement.java:366)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement.execute(PhoenixStatement.java:1775)
>   at sqlline.Commands.execute(Commands.java:822)
>   at sqlline.Commands.sql(Commands.java:732)
>   at sqlline.SqlLine.dispatch(SqlLine.java:807)
>   at sqlline.SqlLine.begin(SqlLine.java:681)
>   at sqlline.SqlLine.start(SqlLine.java:398)
>   at sqlline.SqlLine.main(SqlLine.java:292)



--
This message

[jira] [Resolved] (PHOENIX-5641) Decouple phoenix-queryserver from phoenix-core

2020-03-05 Thread Istvan Toth (Jira) 


 [ 
https://issues.apache.org/jira/browse/PHOENIX-5641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Istvan Toth resolved PHOENIX-5641.
--
Resolution: Fixed

4.x work is tracked in PHOENIX-5641

> Decouple phoenix-queryserver from phoenix-core
> --
>
> Key: PHOENIX-5641
> URL: https://issues.apache.org/jira/browse/PHOENIX-5641
> Project: Phoenix
>  Issue Type: Improvement
>Affects Versions: 5.1.0
>Reporter: Istvan Toth
>Assignee: Istvan Toth
>Priority: Major
> Fix For: 5.1.0
>
> Attachments: PHOENIX-5641.master.v1.patch
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> phoenix-queryserver has been moved to a separate repo, and it's versioning 
> has been decoupled from that of phoenix-core.
> Yet, phoenix-queryserver still uses code from phoenix-core, and phoenix-core 
> in turn contains code that is only used by phoenix-queryserver.
> This causes (at least) the following problems:
>  * Adding new features to PQS is problematic, because it depends on an old 
> released version of phoenix
>  * The phoenix-thin-client includes phoenix code, that is not really necessary
> I propose fully decoupling the PQS code from phoenix proper. This effectively 
> means:
>  * duplicating the PQS specific configuration parameter names and defaults in 
> PQS
>  * copying a minimal amount of code for building the JDBC connection URL
>  * copying the InstanceResolver cache class
> The tests are still dependent on phoenix-core, but I do not consider that a 
> problem.
> If/when this patch lands in PQS, we should also remove the PQS specific 
> parameters from phoenix-core.



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

[jira] [Updated] (PHOENIX-5758) Apply cleanups to 4.x branch

2020-03-05 Thread Istvan Toth (Jira) 


 [ 
https://issues.apache.org/jira/browse/PHOENIX-5758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Istvan Toth updated PHOENIX-5758:
-
Summary: Apply cleanups to 4.x branch  (was: Appl cleanups to 4.x branch)

> Apply cleanups to 4.x branch
> 
>
> Key: PHOENIX-5758
> URL: https://issues.apache.org/jira/browse/PHOENIX-5758
> Project: Phoenix
>  Issue Type: Improvement
>Reporter: Istvan Toth
>Assignee: Istvan Toth
>Priority: Major
>
> There are number of  cleanups that are only present on master, mostly because 
> backporting them to all of the 4.x branches would be too cumbersome.
> Once we have the unified 4.x branch, we should apply these there too.



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

[jira] [Resolved] (PHOENIX-5625) Move Phoenix Pig example directory to phoenix-connectors repo

2020-03-05 Thread Istvan Toth (Jira) 


 [ 
https://issues.apache.org/jira/browse/PHOENIX-5625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Istvan Toth resolved PHOENIX-5625.
--
Resolution: Fixed

4.x work is tracked in PHOENIX-5758

> Move Phoenix Pig example directory to phoenix-connectors repo
> -
>
> Key: PHOENIX-5625
> URL: https://issues.apache.org/jira/browse/PHOENIX-5625
> Project: Phoenix
>  Issue Type: Task
>Affects Versions: 5.1.0
>Reporter: Istvan Toth
>Assignee: Istvan Toth
>Priority: Minor
> Fix For: 5.1.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> phoenix-pig has been removed from the main repo, but the example directory 
> has not been moved to phoenix-connectors.



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

[jira] [Assigned] (PHOENIX-5758) Apply maven cleanups to 4.x branch

2020-03-05 Thread Istvan Toth (Jira) 


 [ 
https://issues.apache.org/jira/browse/PHOENIX-5758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Istvan Toth reassigned PHOENIX-5758:


Assignee: Istvan Toth

> Apply maven cleanups to 4.x branch
> --
>
> Key: PHOENIX-5758
> URL: https://issues.apache.org/jira/browse/PHOENIX-5758
> Project: Phoenix
>  Issue Type: Improvement
>Reporter: Istvan Toth
>Assignee: Istvan Toth
>Priority: Major
>
> There are number of build related cleanups, that are only present on master, 
> mostly because backporting them to all of the 4.x branches would be too 
> cumbersome.
> Once we have the unified 4.x branch, we should apply these there too.



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

[jira] [Updated] (PHOENIX-5758) Appl cleanups to 4.x branch

2020-03-05 Thread Istvan Toth (Jira) 


 [ 
https://issues.apache.org/jira/browse/PHOENIX-5758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Istvan Toth updated PHOENIX-5758:
-
Description: 
There are number of  cleanups that are only present on master, mostly because 
backporting them to all of the 4.x branches would be too cumbersome.

Once we have the unified 4.x branch, we should apply these there too.

  was:
There are number of build related cleanups, that are only present on master, 
mostly because backporting them to all of the 4.x branches would be too 
cumbersome.

Once we have the unified 4.x branch, we should apply these there too.

Summary: Appl cleanups to 4.x branch  (was: Apply maven cleanups to 4.x 
branch)

> Appl cleanups to 4.x branch
> ---
>
> Key: PHOENIX-5758
> URL: https://issues.apache.org/jira/browse/PHOENIX-5758
> Project: Phoenix
>  Issue Type: Improvement
>Reporter: Istvan Toth
>Assignee: Istvan Toth
>Priority: Major
>
> There are number of  cleanups that are only present on master, mostly because 
> backporting them to all of the 4.x branches would be too cumbersome.
> Once we have the unified 4.x branch, we should apply these there too.



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

[jira] [Updated] (PHOENIX-5758) Apply maven cleanups to 4.x branch

2020-03-05 Thread Istvan Toth (Jira) 


 [ 
https://issues.apache.org/jira/browse/PHOENIX-5758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Istvan Toth updated PHOENIX-5758:
-
Summary: Apply maven cleanups to 4.x branch  (was: Apply dependency 
cleanups to 4.x branch)

> Apply maven cleanups to 4.x branch
> --
>
> Key: PHOENIX-5758
> URL: https://issues.apache.org/jira/browse/PHOENIX-5758
> Project: Phoenix
>  Issue Type: Improvement
>Reporter: Istvan Toth
>Priority: Major
>
> There are number of build related cleanups, that are only present on master, 
> mostly because backporting them to all of the 4.x branches would be too 
> cumbersome.
> Once we have the unified 4.x branch, we should apply these there too.



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

[jira] [Created] (PHOENIX-5758) Apply dependency cleanups to 4.x branch

2020-03-05 Thread Istvan Toth (Jira) 
Istvan Toth created PHOENIX-5758:


 Summary: Apply dependency cleanups to 4.x branch
 Key: PHOENIX-5758
 URL: https://issues.apache.org/jira/browse/PHOENIX-5758
 Project: Phoenix
  Issue Type: Improvement
Reporter: Istvan Toth


There are number of build related cleanups, that are only present on master, 
mostly because backporting them to all of the 4.x branches would be too 
cumbersome.

Once we have the unified 4.x branch, we should apply these there too.



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