date:20171103

Re: [VOTE] Release of Apache Phoenix 4.13.0 RC0

2017-11-03 Thread James Taylor

Thanks for the vote, Josh, but FYI there is a new dependency
with com.salesforce.i18n:i18n-util that went in with PHOENIX-4237.

On Fri, Nov 3, 2017 at 8:23 PM, Josh Elser  wrote:

> +1 (binding)
>
> * Can build from source and run unit tests
> * No new deps since 4.12 (implies L is still good)
> * 4.13 tags are deployed and match
> * No unexpected files in src releases
>
>
> On 11/3/17 6:21 PM, James Taylor wrote:
>
>> Hello Everyone,
>>
>> This is a call for a vote on Apache Phoenix 4.13.0 RC0. This is the next
>> minor release of Phoenix 4, compatible with Apache HBase 0.98 and 1.3. The
>> release includes both a source-only release and a convenience binary
>> release for each supported HBase version.
>>
>> This release has feature parity with supported HBase versions and includes
>> the following improvements:
>> - Critical bug fix to prevent snapshot creation of SYSTEM.CATALOG when
>> connecting [1]
>> - Numerous bug fixes around handling of row deletion [2][3][4][5]
>> - Improvements to statistics collection [6][7][8][9]
>> - New COLLATION_KEY built-in function for linguistic sort [10]
>>
>> The source tarball, including signatures, digests, etc can be found at:
>> https://dist.apache.org/repos/dist/dev/phoenix/apache-phoeni
>> x-4.13.0-HBase-0.98-rc0/src/
>> https://dist.apache.org/repos/dist/dev/phoenix/apache-phoeni
>> x-4.13.0-HBase-1.3-rc0/src/
>>
>> The binary artifacts can be found at:
>> https://dist.apache.org/repos/dist/dev/phoenix/apache-phoeni
>> x-4.13.0-HBase-0.98-rc0/bin/
>> https://dist.apache.org/repos/dist/dev/phoenix/apache-phoeni
>> x-4.13.0-HBase-1.3-rc0/bin/
>>
>> For a complete list of changes, see:
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?proje
>> ctId=12315120=12341710
>>
>> Release artifacts are signed with the following key:
>> https://people.apache.org/keys/committer/mujtaba.asc
>> https://dist.apache.org/repos/dist/release/phoenix/KEYS
>>
>> The hash and tag to be voted upon:
>> https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=comm
>> it;h=7e795ac67fd21bd48f49acda3327c83d369aead4
>> https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=tag;
>> h=refs/tags/v4.13.0-HBase-0.98-rc0
>> https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=comm
>> it;h=a09cea6bfb94edd95ce06aa2cb7f229227db5666
>> https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=tag;
>> h=refs/tags/v4.13.0-HBase-1.3-rc0
>> The hash and tag to be voted upon:
>> https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=comm
>> it;h=13a7f97b49704642d67481c58a118a68c2e4c2e5
>> https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=tag;
>> h=refs/tags/v4.12.0-HBase-0.98-rc0
>> https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=comm
>> it;h=e40bbfff1150e56e1ecb7cd22c49cee298496c2b
>> https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=tag;
>> h=refs/tags/v4.12.0-HBase-1.1-rc0
>> https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=comm
>> it;h=d79dd50ff732f2673e1414d970cd4742e2c135de
>> https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=tag;
>> h=refs/tags/v4.12.0-HBase-1.2-rc0
>> https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=comm
>> it;h=f0bc4cdb5bbf96b316c78cc816400b04f63e911b
>> https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=tag;
>> h=refs/tags/v4.12.0-HBase-1.3-rc0
>>
>> Vote will be open for at least 72 hours. Please vote:
>>
>> [ ] +1 approve
>> [ ] +0 no opinion
>> [ ] -1 disapprove (and reason why)
>>
>> Thanks,
>> The Apache Phoenix Team
>>
>> [1] https://issues.apache.org/jira/browse/PHOENIX-4335
>> [2] https://issues.apache.org/jira/browse/PHOENIX-4280
>> [3] https://issues.apache.org/jira/browse/PHOENIX-4290
>> [4] https://issues.apache.org/jira/browse/PHOENIX-4348
>> [5] https://issues.apache.org/jira/browse/PHOENIX-4277
>> [6] https://issues.apache.org/jira/browse/PHOENIX-3368
>> [7] https://issues.apache.org/jira/browse/PHOENIX-4287
>> [8] https://issues.apache.org/jira/browse/PHOENIX-4289
>> [9] https://issues.apache.org/jira/browse/PHOENIX-4343
>> [10] https://issues.apache.org/jira/browse/PHOENIX-4237
>>
>>

Re: [VOTE] Release of Apache Phoenix 4.13.0 RC0

2017-11-03 Thread Josh Elser


+1 (binding)

* Can build from source and run unit tests
* No new deps since 4.12 (implies L is still good)
* 4.13 tags are deployed and match
* No unexpected files in src releases

On 11/3/17 6:21 PM, James Taylor wrote:

Hello Everyone,

This is a call for a vote on Apache Phoenix 4.13.0 RC0. This is the next
minor release of Phoenix 4, compatible with Apache HBase 0.98 and 1.3. The
release includes both a source-only release and a convenience binary
release for each supported HBase version.

This release has feature parity with supported HBase versions and includes
the following improvements:
- Critical bug fix to prevent snapshot creation of SYSTEM.CATALOG when
connecting [1]
- Numerous bug fixes around handling of row deletion [2][3][4][5]
- Improvements to statistics collection [6][7][8][9]
- New COLLATION_KEY built-in function for linguistic sort [10]

The source tarball, including signatures, digests, etc can be found at:
https://dist.apache.org/repos/dist/dev/phoenix/apache-phoenix-4.13.0-HBase-0.98-rc0/src/
https://dist.apache.org/repos/dist/dev/phoenix/apache-phoenix-4.13.0-HBase-1.3-rc0/src/

The binary artifacts can be found at:
https://dist.apache.org/repos/dist/dev/phoenix/apache-phoenix-4.13.0-HBase-0.98-rc0/bin/
https://dist.apache.org/repos/dist/dev/phoenix/apache-phoenix-4.13.0-HBase-1.3-rc0/bin/

For a complete list of changes, see:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315120=12341710

Release artifacts are signed with the following key:
https://people.apache.org/keys/committer/mujtaba.asc
https://dist.apache.org/repos/dist/release/phoenix/KEYS

The hash and tag to be voted upon:
https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=commit;h=7e795ac67fd21bd48f49acda3327c83d369aead4
https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=tag;h=refs/tags/v4.13.0-HBase-0.98-rc0
https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=commit;h=a09cea6bfb94edd95ce06aa2cb7f229227db5666
https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=tag;h=refs/tags/v4.13.0-HBase-1.3-rc0
The hash and tag to be voted upon:
https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=commit;h=13a7f97b49704642d67481c58a118a68c2e4c2e5
https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=tag;h=refs/tags/v4.12.0-HBase-0.98-rc0
https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=commit;h=e40bbfff1150e56e1ecb7cd22c49cee298496c2b
https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=tag;h=refs/tags/v4.12.0-HBase-1.1-rc0
https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=commit;h=d79dd50ff732f2673e1414d970cd4742e2c135de
https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=tag;h=refs/tags/v4.12.0-HBase-1.2-rc0
https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=commit;h=f0bc4cdb5bbf96b316c78cc816400b04f63e911b
https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=tag;h=refs/tags/v4.12.0-HBase-1.3-rc0

Vote will be open for at least 72 hours. Please vote:

[ ] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)

Thanks,
The Apache Phoenix Team

[1] https://issues.apache.org/jira/browse/PHOENIX-4335
[2] https://issues.apache.org/jira/browse/PHOENIX-4280
[3] https://issues.apache.org/jira/browse/PHOENIX-4290
[4] https://issues.apache.org/jira/browse/PHOENIX-4348
[5] https://issues.apache.org/jira/browse/PHOENIX-4277
[6] https://issues.apache.org/jira/browse/PHOENIX-3368
[7] https://issues.apache.org/jira/browse/PHOENIX-4287
[8] https://issues.apache.org/jira/browse/PHOENIX-4289
[9] https://issues.apache.org/jira/browse/PHOENIX-4343
[10] https://issues.apache.org/jira/browse/PHOENIX-4237

[jira] [Commented] (PHOENIX-2370) ResultSetMetaData.getColumnDisplaySize() returns bad value for varchar and varbinary columns

2017-11-03 Thread Hadoop QA (JIRA)


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

Hadoop QA commented on PHOENIX-2370:


{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12883280/PHOENIX-2370_v2.patch
  against master branch at commit a09cea6bfb94edd95ce06aa2cb7f229227db5666.
  ATTACHMENT ID: 12883280

{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:green}+1 lineLengths{color}.  The patch does not introduce lines 
longer than 100

{color:green}+1 core tests{color}.  The patch passed unit tests in .

Test results: 
https://builds.apache.org/job/PreCommit-PHOENIX-Build/1617//testReport/
Console output: 
https://builds.apache.org/job/PreCommit-PHOENIX-Build/1617//console

This message is automatically generated.

> ResultSetMetaData.getColumnDisplaySize() returns bad value for varchar and 
> varbinary columns
> 
>
> Key: PHOENIX-2370
> URL: https://issues.apache.org/jira/browse/PHOENIX-2370
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.5.0
> Environment: Linux lnxx64r6 2.6.32-131.0.15.el6.x86_64 #1 SMP Tue May 
> 10 15:42:40 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux
>Reporter: Sergio Lob
>Assignee: Csaba Skrabak
>Priority: Major
>  Labels: newbie, verify
> Fix For: 4.14.0
>
> Attachments: PHOENIX-2370.patch, PHOENIX-2370_v2.patch
>
>
> ResultSetMetaData.getColumnDisplaySize() returns bad values for varchar and 
> varbinary columns. Specifically, for the following table:
> CREATE TABLE SERGIO (I INTEGER, V10 VARCHAR(10),
> VHUGE VARCHAR(2147483647), V VARCHAR, VB10 VARBINARY(10), VBHUGE 
> VARBINARY(2147483647), VB VARBINARY) ;
> 1. getColumnDisplaySize() returns 20 for all varbinary columns, no matter the 
> defined size. This should return the max possible size of the column, so:
>  getColumnDisplaySize() should return 10 for column VB10,
>  getColumnDisplaySize() should return 2147483647 for column VBHUGE,
>  getColumnDisplaySize() should return 2147483647 for column VB, assuming that 
> a column defined with no size should default to the maximum size.
> 2. getColumnDisplaySize() returns 40 for all varchar columns that are not 
> defined with a size, like in column V in the above CREATE TABLE.  I would 
> think that a VARCHAR column defined with no size parameter should default to 
> the maximum size possible, not to a random number like 40.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (PHOENIX-4342) Surface QueryPlan in MutationPlan

2017-11-03 Thread James Taylor (JIRA)


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

James Taylor commented on PHOENIX-4342:
---

Ok, let’s just keep it the way you had it.

> Surface QueryPlan in MutationPlan
> -
>
> Key: PHOENIX-4342
> URL: https://issues.apache.org/jira/browse/PHOENIX-4342
> Project: Phoenix
>  Issue Type: Improvement
>Reporter: James Taylor
>Assignee: Geoffrey Jacoby
>Priority: Minor
> Attachments: PHOENIX-4342-v2.patch, PHOENIX-4342-v3.patch, 
> PHOENIX-4342-v4.patch, PHOENIX-4342.patch
>
>
> For DELETE statements, it'd be good to be able to get at the QueryPlan 
> through the MutationPlan so we can get more structured information at compile 
> time.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (PHOENIX-4342) Surface QueryPlan in MutationPlan

2017-11-03 Thread Geoffrey Jacoby (JIRA)


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

Geoffrey Jacoby edited comment on PHOENIX-4342 at 11/3/17 11:43 PM:


In most cases that seems true (it simplifies the execute() logic a good bit), 
but changing getExplainPlan() to use the dataPlan results in this test failure:

[ERROR]   
DeleteIT.testPointDeleteRowFromTableWithImmutableIndex:371->testPointDeleteRowFromTableWithImmutableIndex:447
 expected:<[DELETE SINGLE ROW]> but was:<[CLIENT PARALLEL 1-WAY POINT LOOKUP ON 
1 KEY OVER T14
SERVER FILTER BY FIRST KEY ONLY]>

Presumably the test is expecting a MutationPlan ExplainPlan and confused by 
getting the underlying QueryPlan instead?

There's a similar test failure for the point delete local immutable index test.


was (Author: gjacoby):
In most cases that seems true (it simplifies the execute() logic a good bit), 
but changing getExplainPlan() to use the dataPlan results in this test failure:

[ERROR]   
DeleteIT.testPointDeleteRowFromTableWithImmutableIndex:371->testPointDeleteRowFromTableWithImmutableIndex:447
 expected:<[DELETE SINGLE ROW]> but was:<[CLIENT PARALLEL 1-WAY POINT LOOKUP ON 
1 KEY OVER T14
SERVER FILTER BY FIRST KEY ONLY]>

Presumably the test is expecting a MutationPlan ExplainPlan and confused by 
getting the underlying QueryPlan instead?

> Surface QueryPlan in MutationPlan
> -
>
> Key: PHOENIX-4342
> URL: https://issues.apache.org/jira/browse/PHOENIX-4342
> Project: Phoenix
>  Issue Type: Improvement
>Reporter: James Taylor
>Assignee: Geoffrey Jacoby
>Priority: Minor
> Attachments: PHOENIX-4342-v2.patch, PHOENIX-4342-v3.patch, 
> PHOENIX-4342-v4.patch, PHOENIX-4342.patch
>
>
> For DELETE statements, it'd be good to be able to get at the QueryPlan 
> through the MutationPlan so we can get more structured information at compile 
> time.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (PHOENIX-4342) Surface QueryPlan in MutationPlan

2017-11-03 Thread Geoffrey Jacoby (JIRA)


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

Geoffrey Jacoby commented on PHOENIX-4342:
--

In most cases that seems true (it simplifies the execute() logic a good bit), 
but changing getExplainPlan() to use the dataPlan results in this test failure:

[ERROR]   
DeleteIT.testPointDeleteRowFromTableWithImmutableIndex:371->testPointDeleteRowFromTableWithImmutableIndex:447
 expected:<[DELETE SINGLE ROW]> but was:<[CLIENT PARALLEL 1-WAY POINT LOOKUP ON 
1 KEY OVER T14
SERVER FILTER BY FIRST KEY ONLY]>

Presumably the test is expecting a MutationPlan ExplainPlan and confused by 
getting the underlying QueryPlan instead?

> Surface QueryPlan in MutationPlan
> -
>
> Key: PHOENIX-4342
> URL: https://issues.apache.org/jira/browse/PHOENIX-4342
> Project: Phoenix
>  Issue Type: Improvement
>Reporter: James Taylor
>Assignee: Geoffrey Jacoby
>Priority: Minor
> Attachments: PHOENIX-4342-v2.patch, PHOENIX-4342-v3.patch, 
> PHOENIX-4342-v4.patch, PHOENIX-4342.patch
>
>
> For DELETE statements, it'd be good to be able to get at the QueryPlan 
> through the MutationPlan so we can get more structured information at compile 
> time.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (PHOENIX-4342) Surface QueryPlan in MutationPlan

2017-11-03 Thread James Taylor (JIRA)


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

James Taylor commented on PHOENIX-4342:
---

Yes, I believe these could be replaced with dataPlan.

> Surface QueryPlan in MutationPlan
> -
>
> Key: PHOENIX-4342
> URL: https://issues.apache.org/jira/browse/PHOENIX-4342
> Project: Phoenix
>  Issue Type: Improvement
>Reporter: James Taylor
>Assignee: Geoffrey Jacoby
>Priority: Minor
> Attachments: PHOENIX-4342-v2.patch, PHOENIX-4342-v3.patch, 
> PHOENIX-4342-v4.patch, PHOENIX-4342.patch
>
>
> For DELETE statements, it'd be good to be able to get at the QueryPlan 
> through the MutationPlan so we can get more structured information at compile 
> time.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (PHOENIX-2048) change to_char() function to use HALF_UP rounding mode

2017-11-03 Thread Hadoop QA (JIRA)


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

Hadoop QA commented on PHOENIX-2048:


{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12883121/PHOENIX-2048_v2.patch
  against master branch at commit a09cea6bfb94edd95ce06aa2cb7f229227db5666.
  ATTACHMENT ID: 12883121

{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:green}+1 lineLengths{color}.  The patch does not introduce lines 
longer than 100

 {color:red}-1 core tests{color}.  The patch failed these unit tests:
 
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.ConcurrentMutationsIT

Test results: 
https://builds.apache.org/job/PreCommit-PHOENIX-Build/1618//testReport/
Console output: 
https://builds.apache.org/job/PreCommit-PHOENIX-Build/1618//console

This message is automatically generated.

> change to_char() function to use HALF_UP rounding mode
> --
>
> Key: PHOENIX-2048
> URL: https://issues.apache.org/jira/browse/PHOENIX-2048
> Project: Phoenix
>  Issue Type: Improvement
>Affects Versions: verify
>Reporter: Jonathan Leech
>Assignee: Csaba Skrabak
>Priority: Minor
> Fix For: 4.14.0
>
> Attachments: PHOENIX-2048.patch, PHOENIX-2048_v2.patch
>
>
> to_char() function uses the default rounding mode in java DecimalFormat, 
> which is a strange one called HALF_EVEN, which rounds a '5' in the last 
> position either up or down depending on the preceding digit. 
> Change it to HALF_UP so it rounds the same way as the round() function does, 
> or provide a way to override the behavior; e.g. globally or as a client 
> config, or an argument to the to_char() function.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (PHOENIX-4342) Surface QueryPlan in MutationPlan

2017-11-03 Thread Geoffrey Jacoby (JIRA)


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

Geoffrey Jacoby commented on PHOENIX-4342:
--

I kept the existing accessors on MultiRowDeletionPlan having the same behavior 
they did previously, and several of them (e.g getContext(), getExplainPlan(), 
etc) used firstPlan. Can this be replaced with dataPlan?

> Surface QueryPlan in MutationPlan
> -
>
> Key: PHOENIX-4342
> URL: https://issues.apache.org/jira/browse/PHOENIX-4342
> Project: Phoenix
>  Issue Type: Improvement
>Reporter: James Taylor
>Assignee: Geoffrey Jacoby
>Priority: Minor
> Attachments: PHOENIX-4342-v2.patch, PHOENIX-4342-v3.patch, 
> PHOENIX-4342-v4.patch, PHOENIX-4342.patch
>
>
> For DELETE statements, it'd be good to be able to get at the QueryPlan 
> through the MutationPlan so we can get more structured information at compile 
> time.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (PHOENIX-4342) Surface QueryPlan in MutationPlan

2017-11-03 Thread James Taylor (JIRA)


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

James Taylor commented on PHOENIX-4342:
---

+1 with one minor nit on patch. Do we still need firstPlan as a member variable 
here?
{code}
+private class MultiRowDeleteMutationPlan implements MutationPlan {
 private final List plans;
 private final MutationPlan firstPlan;
-
-public MultiDeleteMutationPlan(@NotNull List plans) {
+private final QueryPlan dataPlan;
+
+public MultiRowDeleteMutationPlan(QueryPlan dataPlan, @NotNull 
List plans) {
 Preconditions.checkArgument(!plans.isEmpty());
 this.plans = plans;
 this.firstPlan = plans.get(0);
+this.dataPlan = dataPlan;
 }
{code}

> Surface QueryPlan in MutationPlan
> -
>
> Key: PHOENIX-4342
> URL: https://issues.apache.org/jira/browse/PHOENIX-4342
> Project: Phoenix
>  Issue Type: Improvement
>Reporter: James Taylor
>Assignee: Geoffrey Jacoby
>Priority: Minor
> Attachments: PHOENIX-4342-v2.patch, PHOENIX-4342-v3.patch, 
> PHOENIX-4342-v4.patch, PHOENIX-4342.patch
>
>
> For DELETE statements, it'd be good to be able to get at the QueryPlan 
> through the MutationPlan so we can get more structured information at compile 
> time.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (PHOENIX-4342) Surface QueryPlan in MutationPlan

2017-11-03 Thread James Taylor (JIRA)


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

James Taylor commented on PHOENIX-4342:
---

bq. ConcurrentMutationsiT passes locally on my machine. A flapper?
Yes, flapper. We've improved things a lot, but there are still some flappers.

> Surface QueryPlan in MutationPlan
> -
>
> Key: PHOENIX-4342
> URL: https://issues.apache.org/jira/browse/PHOENIX-4342
> Project: Phoenix
>  Issue Type: Improvement
>Reporter: James Taylor
>Assignee: Geoffrey Jacoby
>Priority: Minor
> Attachments: PHOENIX-4342-v2.patch, PHOENIX-4342-v3.patch, 
> PHOENIX-4342-v4.patch, PHOENIX-4342.patch
>
>
> For DELETE statements, it'd be good to be able to get at the QueryPlan 
> through the MutationPlan so we can get more structured information at compile 
> time.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (PHOENIX-3837) Unable to set property on an index with Alter statement

2017-11-03 Thread James Taylor (JIRA)


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

James Taylor commented on PHOENIX-3837:
---

Some guidance on how to implement this:
- add the {{| (SET (p=fam_properties)) )}} to the {{ALTER INDEX}} grammar rule 
in PhoenixSQL.g
- store the property info in the AlterIndexStatement
- call through to MetaDataClient.addColumn() if the set property information is 
there. I suspect the code will do the right thing as-is.

[~aertoria] - it is possible to workaround the issue sometimes, but we'd like a 
way to set properties in general on indexes.

> Unable to set property on an index with Alter statement
> ---
>
> Key: PHOENIX-3837
> URL: https://issues.apache.org/jira/browse/PHOENIX-3837
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.10.0
>Reporter: Mujtaba Chohan
>Assignee: Ethan Wang
>Priority: Major
> Fix For: 4.14.0
>
>
> {{ALTER INDEX IDX_T ON T SET GUIDE_POSTS_WIDTH=1}}
> {noformat}
> Error: ERROR 601 (42P00): Syntax error. Encountered "SET" at line 1, column 
> 102. (state=42P00,code=601)
> org.apache.phoenix.exception.PhoenixParserException: ERROR 601 (42P00): 
> Syntax error. Encountered "SET" at line 1, column 102.
> at 
> org.apache.phoenix.exception.PhoenixParserException.newException(PhoenixParserException.java:33)
> at org.apache.phoenix.parse.SQLParser.parseStatement(SQLParser.java:111)
> at 
> org.apache.phoenix.jdbc.PhoenixStatement$PhoenixStatementParser.parseStatement(PhoenixStatement.java:1299)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (PHOENIX-4323) LocalIndexes could fail if your data row is not in the same region as your index region

2017-11-03 Thread James Taylor (JIRA)


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

James Taylor edited comment on PHOENIX-4323 at 11/3/17 10:56 PM:
-

[~rajeshbabu] - though the test is contrived, this could potentially happen if 
local index rows appear *after* the region end key (i.e. after data table 
rows). Any thoughts on how to best prevent this? Can the split policy handle 
this?


was (Author: jamestaylor):
[~rajeshbabu] - though the test is contrived, this could potentially happen if 
local index rows appear *after* data table rows. Any thoughts on how to best 
prevent this? Can the split policy handle this?

> 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
>Priority: Major
> 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)

[jira] [Commented] (PHOENIX-4323) LocalIndexes could fail if your data row is not in the same region as your index region

2017-11-03 Thread James Taylor (JIRA)


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

James Taylor commented on PHOENIX-4323:
---

[~rajeshbabu] - though the test is contrived, this could potentially happen if 
local index rows appear *after* data table rows. Any thoughts on how to best 
prevent this? Can the split policy handle this?

> 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
>Priority: Major
> 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)

[jira] [Commented] (PHOENIX-3460) Namespace separator ":" should not be allowed in table or schema name

2017-11-03 Thread James Taylor (JIRA)


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

James Taylor commented on PHOENIX-3460:
---

FWIW, if a user is counting on some functionality, there needs to be both a) 
documentation, and b) a unit test that will break if the functionality changes. 
Otherwise, it's subject to change.

> Namespace separator ":" should not be allowed in table or schema name
> -
>
> Key: PHOENIX-3460
> URL: https://issues.apache.org/jira/browse/PHOENIX-3460
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.8.0
> Environment: HDP 2.5
>Reporter: Xindian Long
>Assignee: Thomas D'Silva
>Priority: Major
>  Labels: namespaces, phoenix, spark
> Fix For: 4.13.0
>
> Attachments: 0001-Phoenix-fix.patch, PHOENIX-3460-v2.patch, 
> PHOENIX-3460-v2.patch, PHOENIX-3460.patch, SchemaUtil.java
>
>
> I am testing some code using Phoenix Spark plug in to read a Phoenix table 
> with a namespace prefix in the table name (the table is created as a phoenix 
> table not a hbase table), but it returns an TableNotFoundException.
> The table is obviously there because I can query it using plain phoenix sql 
> through Squirrel. In addition, using spark sql to query it has no problem at 
> all.
> I am running on the HDP 2.5 platform, with phoenix 4.7.0.2.5.0.0-1245
> The problem does not exist at all when I was running the same code on HDP 2.4 
> cluster, with phoenix 4.4.
> Neither does the problem occur when I query a table without a namespace 
> prefix in the DB table name, on HDP 2.5
> The log is in the attached file: tableNoFound.txt
> My testing code is also attached.
> The weird thing is in the attached code, if I run testSpark alone it gives 
> the above exception, but if I run the testJdbc first, and followed by 
> testSpark, both of them work.
>  After changing to create table by using
> create table ACME.ENDPOINT_STATUS
> The phoenix-spark plug in seems working. I also find some weird behavior,
> If I do both the following
> create table ACME.ENDPOINT_STATUS ...
> create table "ACME:ENDPOINT_STATUS" ...
> Both table shows up in phoenix, the first one shows as Schema ACME, and table 
> name ENDPOINT_STATUS, and the later on shows as scheme none, and table name 
> ACME:ENDPOINT_STATUS.
> However, in HBASE, I only see one table ACME:ENDPOINT_STATUS. In addition, 
> upserts in the table ACME.ENDPOINT_STATUS show up in the other table, so is 
> the other way around.
>  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (PHOENIX-4291) Merge release script for mac and linux

2017-11-03 Thread Hudson (JIRA)


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

Hudson commented on PHOENIX-4291:
-

FAILURE: Integrated in Jenkins build Phoenix-master #1868 (See 
[https://builds.apache.org/job/Phoenix-master/1868/])
PHOENIX-4291 Addendum - Merge release script for mac and linux (mujtaba: rev 
a09cea6bfb94edd95ce06aa2cb7f229227db5666)
* (edit) dev/make_rc.sh


> Merge release script for mac and linux
> --
>
> Key: PHOENIX-4291
> URL: https://issues.apache.org/jira/browse/PHOENIX-4291
> Project: Phoenix
>  Issue Type: Improvement
>Affects Versions: 4.12.0
>Reporter: Mujtaba Chohan
>Assignee: Mujtaba Chohan
> Fix For: 4.13.0
>
> Attachments: PHOENIX-4291.patch
>
>
> Merging make_rc.sh and make_rc_on_mac.sh to make_rc_sh. This is based on 
> changes that [~jamestaylor] had in place to execute the script on a Mac.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (PHOENIX-4342) Surface QueryPlan in MutationPlan

2017-11-03 Thread Geoffrey Jacoby (JIRA)


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

Geoffrey Jacoby commented on PHOENIX-4342:
--

ConcurrentMutationsiT passes locally on my machine. A flapper?

> Surface QueryPlan in MutationPlan
> -
>
> Key: PHOENIX-4342
> URL: https://issues.apache.org/jira/browse/PHOENIX-4342
> Project: Phoenix
>  Issue Type: Improvement
>Reporter: James Taylor
>Assignee: Geoffrey Jacoby
>Priority: Minor
> Attachments: PHOENIX-4342-v2.patch, PHOENIX-4342-v3.patch, 
> PHOENIX-4342-v4.patch, PHOENIX-4342.patch
>
>
> For DELETE statements, it'd be good to be able to get at the QueryPlan 
> through the MutationPlan so we can get more structured information at compile 
> time.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[VOTE] Release of Apache Phoenix 4.13.0 RC0

2017-11-03 Thread James Taylor

Hello Everyone,

This is a call for a vote on Apache Phoenix 4.13.0 RC0. This is the next
minor release of Phoenix 4, compatible with Apache HBase 0.98 and 1.3. The
release includes both a source-only release and a convenience binary
release for each supported HBase version.

This release has feature parity with supported HBase versions and includes
the following improvements:
- Critical bug fix to prevent snapshot creation of SYSTEM.CATALOG when
connecting [1]
- Numerous bug fixes around handling of row deletion [2][3][4][5]
- Improvements to statistics collection [6][7][8][9]
- New COLLATION_KEY built-in function for linguistic sort [10]

The source tarball, including signatures, digests, etc can be found at:
https://dist.apache.org/repos/dist/dev/phoenix/apache-phoenix-4.13.0-HBase-0.98-rc0/src/
https://dist.apache.org/repos/dist/dev/phoenix/apache-phoenix-4.13.0-HBase-1.3-rc0/src/

The binary artifacts can be found at:
https://dist.apache.org/repos/dist/dev/phoenix/apache-phoenix-4.13.0-HBase-0.98-rc0/bin/
https://dist.apache.org/repos/dist/dev/phoenix/apache-phoenix-4.13.0-HBase-1.3-rc0/bin/

For a complete list of changes, see:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315120=12341710

Release artifacts are signed with the following key:
https://people.apache.org/keys/committer/mujtaba.asc
https://dist.apache.org/repos/dist/release/phoenix/KEYS

The hash and tag to be voted upon:
https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=commit;h=7e795ac67fd21bd48f49acda3327c83d369aead4
https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=tag;h=refs/tags/v4.13.0-HBase-0.98-rc0
https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=commit;h=a09cea6bfb94edd95ce06aa2cb7f229227db5666
https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=tag;h=refs/tags/v4.13.0-HBase-1.3-rc0
The hash and tag to be voted upon:
https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=commit;h=13a7f97b49704642d67481c58a118a68c2e4c2e5
https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=tag;h=refs/tags/v4.12.0-HBase-0.98-rc0
https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=commit;h=e40bbfff1150e56e1ecb7cd22c49cee298496c2b
https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=tag;h=refs/tags/v4.12.0-HBase-1.1-rc0
https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=commit;h=d79dd50ff732f2673e1414d970cd4742e2c135de
https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=tag;h=refs/tags/v4.12.0-HBase-1.2-rc0
https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=commit;h=f0bc4cdb5bbf96b316c78cc816400b04f63e911b
https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=tag;h=refs/tags/v4.12.0-HBase-1.3-rc0

Vote will be open for at least 72 hours. Please vote:

[ ] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)

Thanks,
The Apache Phoenix Team

[1] https://issues.apache.org/jira/browse/PHOENIX-4335
[2] https://issues.apache.org/jira/browse/PHOENIX-4280
[3] https://issues.apache.org/jira/browse/PHOENIX-4290
[4] https://issues.apache.org/jira/browse/PHOENIX-4348
[5] https://issues.apache.org/jira/browse/PHOENIX-4277
[6] https://issues.apache.org/jira/browse/PHOENIX-3368
[7] https://issues.apache.org/jira/browse/PHOENIX-4287
[8] https://issues.apache.org/jira/browse/PHOENIX-4289
[9] https://issues.apache.org/jira/browse/PHOENIX-4343
[10] https://issues.apache.org/jira/browse/PHOENIX-4237

[jira] [Updated] (PHOENIX-4242) Fix Indexer post-compact hook logging of NPE and TableNotFound

2017-11-03 Thread James Taylor (JIRA)


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

James Taylor updated PHOENIX-4242:
--
Fix Version/s: (was: 4.12.1)

> Fix Indexer post-compact hook logging of NPE and TableNotFound
> --
>
> Key: PHOENIX-4242
> URL: https://issues.apache.org/jira/browse/PHOENIX-4242
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.12.0
>Reporter: Vincent Poon
>Assignee: Vincent Poon
>Priority: Major
> Fix For: 4.13.0
>
> Attachments: PHOENIX-4242.v2.master.patch, 
> PHOENIX-4242.v3.master.patch, PHOENIX-4242.v4.master.patch, 
> PHOENIX-4747.v1.master.patch
>
>
> The post-compact hook in the Indexer seems to log extraneous log messages 
> indicating NPE or TableNotFound.  The TableNotFound exceptions seem to 
> indicate actual table names prefixed with MERGE or RESTORE, and sometimes 
> suffixed with a digit, so perhaps these are views or something similar.
> Examples:
> 2017-09-28 13:35:03,118 WARN  [ctions-1506410238599] index.Indexer - Unable 
> to permanently disable indexes being partially rebuild for SYSTEM.SEQUENCE
> java.lang.NullPointerException
> 2017-09-28 10:20:56,406 WARN  [ctions-1506410238415] index.Indexer - Unable 
> to permanently disable indexes being partially rebuild for 
> MERGE_PLATFORM_ENTITY.PLATFORM_IMMUTABLE_ENTITY_DATA2
> org.apache.phoenix.schema.TableNotFoundException: ERROR 1012 (42M03): Table 
> undefined. tableName=MERGE_PLATFORM_ENTITY.PLATFORM_IMMUTABLE_ENTITY_DATA2



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (PHOENIX-4229) Parent-Child linking rows in System.Catalog break tenant view replication

2017-11-03 Thread James Taylor (JIRA)


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

James Taylor updated PHOENIX-4229:
--
Fix Version/s: (was: 4.12.1)

> Parent-Child linking rows in System.Catalog break tenant view replication
> -
>
> Key: PHOENIX-4229
> URL: https://issues.apache.org/jira/browse/PHOENIX-4229
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.11.0, 4.12.0
>Reporter: Geoffrey Jacoby
>Assignee: Geoffrey Jacoby
>Priority: Major
> Fix For: 4.13.0
>
> Attachments: PHOENIX-4229-v2.patch, PHOENIX-4229-v3.patch, 
> PHOENIX-4229.patch
>
>
> PHOENIX-2051 introduced new Parent-Child linking rows to System.Catalog that 
> speed up view deletion. Unfortunately, this breaks assumptions in 
> PHOENIX-3639, which gives a way to replicate tenant views from one cluster to 
> another. (It assumes that all the metadata for a tenant view is owned by the 
> tenant -- the linking rows are not.) 
> PHOENIX-3639 was a workaround in the first place to the more fundamental 
> design problem that Phoenix places the metadata for both table schemas -- 
> which should never be replicated -- in the same table and column family as 
> the metadata for tenant views, which should be replicated. 
> Note that the linking rows also make it more difficult to ever split these 
> two datasets apart, as proposed in PHOENIX-3520.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (PHOENIX-3556) Remove usage of com.google.common.collect.Iterators.emptyIterator()

2017-11-03 Thread James Taylor (JIRA)


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

James Taylor updated PHOENIX-3556:
--
Fix Version/s: (was: 4.12.1)

> Remove usage of com.google.common.collect.Iterators.emptyIterator()
> ---
>
> Key: PHOENIX-3556
> URL: https://issues.apache.org/jira/browse/PHOENIX-3556
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.5.2
> Environment: MacOs, Phoenix 4.5.2-HBase-0.98, Guava 20.0
>Reporter: Bo Gao
>Assignee: Thomas D'Silva
>Priority: Critical
> Fix For: 4.13.0
>
> Attachments: PHOENIX-3556-v2.patch, PHOENIX-3556.patch
>
>
> I am working on a project with Google ads-lib latest version 2.22.0(Dec, 
> 2016), and it requires Guava version 20.0(Oct, 2016). My phoneix-core version 
> is 4.5.2-HBase-0.98. I got the following exception when trying to get Phoenix 
> connection:
> {noformat}
> java.lang.IllegalAccessError: tried to access method 
> com.google.common.collect.Iterators.emptyIterator()Lcom/google/common/collect/UnmodifiableIterator;
>  from class org.apache.phoenix.schema.MetaDataClient
>   at 
> org.apache.phoenix.schema.MetaDataClient.createTableInternal(MetaDataClient.java:1501)
>  ~[phoenix-core-4.5.2-HBase-0.98.jar:4.5.2-HBase-0.98]
>   at 
> org.apache.phoenix.schema.MetaDataClient.createTable(MetaDataClient.java:751) 
> ~[phoenix-core-4.5.2-HBase-0.98.jar:4.5.2-HBase-0.98]
>   at 
> org.apache.phoenix.compile.CreateTableCompiler$2.execute(CreateTableCompiler.java:186)
>  ~[phoenix-core-4.5.2-HBase-0.98.jar:4.5.2-HBase-0.98]
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:315) 
> ~[phoenix-core-4.5.2-HBase-0.98.jar:4.5.2-HBase-0.98]
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:307) 
> ~[phoenix-core-4.5.2-HBase-0.98.jar:4.5.2-HBase-0.98]
>   at org.apache.phoenix.call.CallRunner.run(CallRunner.java:53) 
> ~[phoenix-core-4.5.2-HBase-0.98.jar:4.5.2-HBase-0.98]
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement.executeMutation(PhoenixStatement.java:305)
>  ~[phoenix-core-4.5.2-HBase-0.98.jar:4.5.2-HBase-0.98]
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement.executeUpdate(PhoenixStatement.java:1364)
>  ~[phoenix-core-4.5.2-HBase-0.98.jar:4.5.2-HBase-0.98]
>   at 
> org.apache.phoenix.query.ConnectionQueryServicesImpl$12.call(ConnectionQueryServicesImpl.java:1927)
>  ~[phoenix-core-4.5.2-HBase-0.98.jar:4.5.2-HBase-0.98]
>   at 
> org.apache.phoenix.query.ConnectionQueryServicesImpl$12.call(ConnectionQueryServicesImpl.java:1896)
>  ~[phoenix-core-4.5.2-HBase-0.98.jar:4.5.2-HBase-0.98]
>   at 
> org.apache.phoenix.util.PhoenixContextExecutor.call(PhoenixContextExecutor.java:77)
>  ~[phoenix-core-4.5.2-HBase-0.98.jar:4.5.2-HBase-0.98]
>   at 
> org.apache.phoenix.query.ConnectionQueryServicesImpl.init(ConnectionQueryServicesImpl.java:1896)
>  ~[phoenix-core-4.5.2-HBase-0.98.jar:4.5.2-HBase-0.98]
>   at 
> org.apache.phoenix.jdbc.PhoenixDriver.getConnectionQueryServices(PhoenixDriver.java:180)
>  ~[phoenix-core-4.5.2-HBase-0.98.jar:4.5.2-HBase-0.98]
>   at 
> org.apache.phoenix.jdbc.PhoenixEmbeddedDriver.connect(PhoenixEmbeddedDriver.java:132)
>  ~[phoenix-core-4.5.2-HBase-0.98.jar:4.5.2-HBase-0.98]
>   at 
> org.apache.phoenix.jdbc.PhoenixDriver.connect(PhoenixDriver.java:151) 
> ~[phoenix-core-4.5.2-HBase-0.98.jar:4.5.2-HBase-0.98]
>   at java.sql.DriverManager.getConnection(DriverManager.java:664) 
> ~[na:1.8.0_65]
>   at java.sql.DriverManager.getConnection(DriverManager.java:247) 
> ~[na:1.8.0_65]
> {noformat}
> The issue is that from Guava 20.0 Google changed the visibility of 
> com.google.common.collect.Iterators#emptyIterator() from public to default as 
> it was announced earlier to be deprecated.
> I checked several versions of phoenix-core from old to new, looks like all 
> versions are using com.google.common.collect.Iterators#emptyIterator() in 
> org.apache.phoenix.schema.MetaDataClient. So the affected versions should be 
> all.
> Better to replace the usage of emptyIterator() as 
> https://google.github.io/guava/releases/18.0/api/docs/com/google/common/collect/Iterators.html#emptyIterator()
>  recommends.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (PHOENIX-4291) Merge release script for mac and linux

2017-11-03 Thread James Taylor (JIRA)


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

James Taylor updated PHOENIX-4291:
--
Fix Version/s: (was: 4.12.1)
   4.13.0

> Merge release script for mac and linux
> --
>
> Key: PHOENIX-4291
> URL: https://issues.apache.org/jira/browse/PHOENIX-4291
> Project: Phoenix
>  Issue Type: Improvement
>Affects Versions: 4.12.0
>Reporter: Mujtaba Chohan
>Assignee: Mujtaba Chohan
> Fix For: 4.13.0
>
> Attachments: PHOENIX-4291.patch
>
>
> Merging make_rc.sh and make_rc_on_mac.sh to make_rc_sh. This is based on 
> changes that [~jamestaylor] had in place to execute the script on a Mac.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (PHOENIX-4292) Filters on Tables and Views with composite PK of VARCHAR fields with sort direction DESC do not work

2017-11-03 Thread James Taylor (JIRA)


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

James Taylor updated PHOENIX-4292:
--
Fix Version/s: (was: 4.12.1)

> Filters on Tables and Views with composite PK of VARCHAR fields with sort 
> direction DESC do not work
> 
>
> Key: PHOENIX-4292
> URL: https://issues.apache.org/jira/browse/PHOENIX-4292
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.10.0
>Reporter: Jan Fernando
>Assignee: Thomas D'Silva
>Priority: Major
> Fix For: 4.13.0
>
> Attachments: PHOENIX-4292-addendum.patch, PHOENIX-4292.patch
>
>
> We noticed that in certain instances on tables and views that were defined 
> with a Composite PK and where the elements of the PK were all DESC that 
> queries exhibited strange behavior and did not return results when expected. 
> A simple query on the first element of the PK returned 0 results e.g SELECT * 
> FROM MY_TABLE WHERE PK1 = 'myvaluethatexists' would return 0 results.
> After some investigation it appears that querying tables and views with a 
> Composite PK that :
> a) have multiple VARCHAR columns in the PK
> b) the sort direction of all the VARCHAR columns is defined as DESC 
>  does not work correctly and the filters are not honored and SQL appears 
> broken to the end user.
> Detailed repro steps:
> ---
> -- 1. Create Global Base Table
> 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
> -- 2. Create various TENANT SPECIFIC VIEWS i.e. use a tenant specific 
> connection
> CREATE VIEW IF NOT EXISTS TEST."abc" (pk1 VARCHAR(10) NOT NULL, pk2 
> VARCHAR(10) NOT NULL, col1 DATE,  col3 DECIMAL CONSTRAINT PK PRIMARY KEY (pk1 
> DESC, pk2 DESC)) AS SELECT * FROM TEST.BASETABLE WHERE KEY_PREFIX = 'abc';
> CREATE VIEW IF NOT EXISTS TEST."ab2" (pk1 VARCHAR(10) NOT NULL, pk2 
> VARCHAR(10) NOT NULL, col1 DATE,  col3 DECIMAL CONSTRAINT PK PRIMARY KEY (pk1 
> DESC, pk2 ASC)) AS SELECT * FROM TEST.BASETABLE WHERE KEY_PREFIX = 'ab2';
> CREATE VIEW IF NOT EXISTS TEST."ab3" (pk1 DATE(10) NOT NULL, pk2 DATE(10) NOT 
> NULL, col1 VARCHAR(10),  col3 DECIMAL CONSTRAINT PK PRIMARY KEY (pk1 DESC, 
> pk2 DESC)) AS SELECT * FROM TEST.BASETABLE WHERE KEY_PREFIX = 'ab3';
> CREATE VIEW IF NOT EXISTS TEST."ab4" (pk1 DATE(10) NOT NULL, pk2 DECIMAL NOT 
> NULL, pk3 VARCHAR(10) NOT NULL,  col3 DECIMAL CONSTRAINT PK PRIMARY KEY (pk1 
> DESC, pk2 DESC, pk3 DESC)) AS SELECT * FROM TEST.BASETABLE WHERE KEY_PREFIX = 
> 'ab4';
> -- 3. Test cases that exhibit this issues
> -- SIMULATE EQUALITY QUERY PROBLEMS: View with composite PK with multiple PK 
> values of VARCHAR values DESC
> upsert into TEST."abc" (pk1, pk2, col1, col3) VALUES ('testa', 'testb', 
> TO_DATE('2017-10-16 22:00:00', '-MM-dd HH:mm:ss'), 10); 
> upsert into TEST."abc" (pk1, pk2, col1, col3) VALUES ('testa', 'testc', 
> TO_DATE('2017-10-16 22:00:00', '-MM-dd HH:mm:ss'), 10); 
> upsert into TEST."abc" (pk1, pk2, col1, col3) VALUES ('testa', 'testd', 
> TO_DATE('2017-10-16 22:00:00', '-MM-dd HH:mm:ss'), 10); 
> upsert into TEST."abc" (pk1, pk2, col1, col3) VALUES ('testa', 'teste', 
> TO_DATE('2017-10-16 22:00:00', '-MM-dd HH:mm:ss'), 10); 
> upsert into TEST."abc" (pk1, pk2, col1, col3) VALUES ('testb', 'testa', 
> TO_DATE('2017-10-16 22:00:00', '-MM-dd HH:mm:ss'), 10); 
> SELECT * FROM TEST."abc" WHERE pk1 = 'testa'; -- INCORRECT RESULT: This query 
> returns no records, expected to return 4
> SELECT * FROM TEST."abc"; -- Returns 5 rows as expected
> SELECT * FROM TEST."abc" WHERE pk1 >= 'testa'; -- INCORRECT RESULT: This 
> query returns 1 record, expected to return 5
> SELECT * FROM TEST."abc" WHERE pk1 <= 'testa';  -- Returns 4 rows as expected
> SELECT * FROM TEST."abc" WHERE pk1 > 'testa'; -- Returns 1 row as expected
> SELECT * FROM TEST."abc" WHERE pk1 < 'testa'; -- INCORRECT RESULT: This query 
> returns 1 record, expected to return 0
> -- The following are cases where everything works as expected and which don't 
> have composite VARCHAR PKs
> -- DEMONOSTRATE NO QUERY PROBLEMS WHEN HAVE VIEW WITH SINGLE DESC TEXT PK: 
> View with composite PK with single pk value DESC
> upsert into TEST."ab2" (pk1, pk2, col1, col3) VALUES ('testa', 'testb', 
> TO_DATE('2017-10-16 22:00:00', '-MM-dd HH:mm:ss'), 10); 
> upsert into TEST."ab2" (pk1, pk2, col1, col3) VALUES ('testa', 'testc', 
> TO_DATE('2017-10-16 22:00:00', '-MM-dd HH:mm:ss'), 10); 
> upsert into TEST."ab2"

[jira] [Updated] (PHOENIX-4294) Allow scalar function to declare that it's not thread safe

2017-11-03 Thread James Taylor (JIRA)


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

James Taylor updated PHOENIX-4294:
--
Fix Version/s: (was: 4.12.1)

> Allow scalar function to declare that it's not thread safe
> --
>
> Key: PHOENIX-4294
> URL: https://issues.apache.org/jira/browse/PHOENIX-4294
> Project: Phoenix
>  Issue Type: Improvement
>Reporter: James Taylor
>Assignee: James Taylor
>Priority: Major
> Fix For: 4.13.0
>
> Attachments: PHOENIX-4294.patch
>
>
> We have our CloneExpressionVisitor which determines when an expression 
> subtree needs to be cloned. For ease of use and clarity, we should have a new 
> method on ScalarFunction that may be overridden to determine when the 
> function is cloned versus not cloned.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (PHOENIX-4269) IndexScrutinyToolIT is flapping

2017-11-03 Thread James Taylor (JIRA)


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

James Taylor updated PHOENIX-4269:
--
Fix Version/s: (was: 4.12.1)

> IndexScrutinyToolIT is flapping
> ---
>
> Key: PHOENIX-4269
> URL: https://issues.apache.org/jira/browse/PHOENIX-4269
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.13.0
>Reporter: James Taylor
>Assignee: Vincent Poon
>Priority: Major
> Fix For: 4.13.0
>
> Attachments: PHOENIX-4269.master.patch
>
>
> In a local test run (not able to repro when run separately), I saw the 
> following failure:
> {code}
> [ERROR] Tests run: 20, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 
> 193.228 s <<< FAILURE! - in org.apache.phoenix.end2end.IndexScrutinyToolIT
> [ERROR] 
> testBothDataAndIndexAsSource[0](org.apache.phoenix.end2end.IndexScrutinyToolIT)
>   Time elapsed: 11.708 s  <<< FAILURE!
> java.lang.AssertionError: expected:<1> but was:<0>
>   at 
> org.apache.phoenix.end2end.IndexScrutinyToolIT.testBothDataAndIndexAsSource(IndexScrutinyToolIT.java:344)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (PHOENIX-4295) Fix argument order for StatsCollectorIT derived classes

2017-11-03 Thread James Taylor (JIRA)


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

James Taylor updated PHOENIX-4295:
--
Fix Version/s: (was: 4.12.1)

> Fix argument order for StatsCollectorIT derived classes
> ---
>
> Key: PHOENIX-4295
> URL: https://issues.apache.org/jira/browse/PHOENIX-4295
> Project: Phoenix
>  Issue Type: Test
>Reporter: James Taylor
>Assignee: James Taylor
>Priority: Major
> Fix For: 4.13.0
>
> Attachments: PHOENIX-4295.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (PHOENIX-4333) Stats - Incorrect estimate when stats are updated on a tenant specific view

2017-11-03 Thread James Taylor (JIRA)


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

James Taylor updated PHOENIX-4333:
--
Fix Version/s: 4.14.0

> Stats - Incorrect estimate when stats are updated on a tenant specific view
> ---
>
> Key: PHOENIX-4333
> URL: https://issues.apache.org/jira/browse/PHOENIX-4333
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.12.0
>Reporter: Mujtaba Chohan
>Assignee: Samarth Jain
>Priority: Major
> Fix For: 4.14.0
>
> Attachments: PHOENIX-4333_test.patch, PHOENIX-4333_v1.patch, 
> PHOENIX-4333_v2.patch
>
>
> Consider two tenants A, B with tenant specific view on 2 separate 
> regions/region servers.
> {noformat}
> Region 1 keys:
> A,1
> A,2
> B,1
> Region 2 keys:
> B,2
> B,3
> {noformat}
> When stats are updated on tenant A view. Querying stats on tenant B view 
> yield partial results (only contains stats for B,1) which are incorrect even 
> though it shows updated timestamp as current.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (PHOENIX-4283) Group By statement truncating BIGINTs

2017-11-03 Thread James Taylor (JIRA)


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

James Taylor updated PHOENIX-4283:
--
Fix Version/s: (was: 4.12.1)
   4.13.0

> Group By statement truncating BIGINTs
> -
>
> Key: PHOENIX-4283
> URL: https://issues.apache.org/jira/browse/PHOENIX-4283
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.11.0
>Reporter: Steven Sadowski
>Assignee: Ethan Wang
>Priority: Major
> Fix For: 4.13.0
>
> Attachments: PHOENIX-4283-v3.patch, PHOENIX-4283.patch
>
>
> *Versions:*
> Phoenix 4.11.0
> HBase: 1.3.1
> (Amazon EMR: 5.8.0)
> *Steps to reproduce:*
> 1. From the `sqlline-thin.py` client setup the following table:
> {code:sql}
> CREATE TABLE test_table (
> a BIGINT NOT NULL, 
> c BIGINT NOT NULL
> CONSTRAINT PK PRIMARY KEY (a, c)
> );
> UPSERT INTO test_table(a,c) VALUES(444, 555);
> SELECT a FROM (SELECT a, c FROM test_table GROUP BY a, c) GROUP BY a, c;
> {code}
> *Expected Result:*
> {code:sql}
> +--+
> |  A   |
> +--+
> | 444  |
> +--+
> {code}
> *Actual Result:*
> {code:sql}
> +--+
> |  A   |
> +--+
> | 400  |
> +--+
> {code}
> *Comments:*
> Having the two Group By statements together seems to truncate the last 6 or 
> so digits of the final result. Removing the outer (or either) group by will 
> produce the correct result.
> Please fix the Group by statement to not truncate the outer result's value.



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

2017-11-03 Thread James Taylor (JIRA)


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

James Taylor updated PHOENIX-4289:
--
Fix Version/s: (was: 4.12.1)
   4.13.0

> 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
>Priority: Major
>  Labels: localIndex
> Fix For: 4.13.0
>
> Attachments: PHOENIX-4289.patch, PHOENIX-4289_v2.patch, 
> PHOENIX-4289_v3.patch, PHOENIX-4289_v4.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

[jira] [Resolved] (PHOENIX-4343) In CREATE TABLE allow setting guide post width only on base data tables

2017-11-03 Thread James Taylor (JIRA)


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

James Taylor resolved PHOENIX-4343.
---
Resolution: Fixed

> In CREATE TABLE allow setting guide post width only on base data tables
> ---
>
> Key: PHOENIX-4343
> URL: https://issues.apache.org/jira/browse/PHOENIX-4343
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Samarth Jain
>Assignee: Samarth Jain
>Priority: Major
> Fix For: 4.13.0
>
> Attachments: PHOENIX-4343.patch, PHOENIX-4343_v2.patch, 
> PHOENIX-4343_v3.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (PHOENIX-4343) In CREATE TABLE allow setting guide post width only on base data tables

2017-11-03 Thread James Taylor (JIRA)


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

James Taylor updated PHOENIX-4343:
--
Fix Version/s: 4.13.0

> In CREATE TABLE allow setting guide post width only on base data tables
> ---
>
> Key: PHOENIX-4343
> URL: https://issues.apache.org/jira/browse/PHOENIX-4343
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Samarth Jain
>Assignee: Samarth Jain
>Priority: Major
> Fix For: 4.13.0
>
> Attachments: PHOENIX-4343.patch, PHOENIX-4343_v2.patch, 
> PHOENIX-4343_v3.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (PHOENIX-3368) Default GUIDE_POSTS_WIDTH of an index to value from its table

2017-11-03 Thread James Taylor (JIRA)


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

James Taylor resolved PHOENIX-3368.
---
   Resolution: Duplicate
Fix Version/s: (was: 4.14.0)
   4.13.0

Duplicate of PHOENIX-4332

> Default GUIDE_POSTS_WIDTH of an index to value from its table
> -
>
> Key: PHOENIX-3368
> URL: https://issues.apache.org/jira/browse/PHOENIX-3368
> Project: Phoenix
>  Issue Type: Bug
>Reporter: James Taylor
>Priority: Major
> Fix For: 4.13.0
>
>
> Currently the GUIDE_POSTS_WIDTH property on an index is independent from its 
> value for its table. We should default the index to the same value as the 
> table when the index is created.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (PHOENIX-4342) Surface QueryPlan in MutationPlan

2017-11-03 Thread Hadoop QA (JIRA)


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

Hadoop QA commented on PHOENIX-4342:


{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12895961/PHOENIX-4342-v4.patch
  against master branch at commit a09cea6bfb94edd95ce06aa2cb7f229227db5666.
  ATTACHMENT ID: 12895961

{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:
+mutationPlans.add(new SingleRowDeleteMutationPlan(plan, 
connection, maxSize, maxSizeBytes));
+return new ServerSelectDeleteMutationPlan(dataPlan, connection, 
aggPlan, projector, maxSize, maxSizeBytes);
+return new ClientSelectDeleteMutationPlan(targetTableRef, 
dataPlan, bestPlan, hasPreOrPostProcessing,
+parallelIteratorFactory, otherTableRefs, 
projectedTableRef, maxSize, maxSizeBytes, connection);
+public SingleRowDeleteMutationPlan(QueryPlan dataPlan, 
PhoenixConnection connection, int maxSize, int maxSizeBytes) {
+Map mutation = 
Maps.newHashMapWithExpectedSize(ranges.getPointLookupCount());
+
statement.getConnection().getStatementExecutionCounter(), 
NULL_ROWTIMESTAMP_INFO, null));
+return new MutationState(dataPlan.getTableRef(), mutation, 0, 
maxSize, maxSizeBytes, connection);
+public ServerSelectDeleteMutationPlan(QueryPlan dataPlan, 
PhoenixConnection connection, QueryPlan aggPlan,
+  RowProjector projector, int 
maxSize, int maxSizeBytes) {

 {color:red}-1 core tests{color}.  The patch failed these unit tests:
 
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.ConcurrentMutationsIT

Test results: 
https://builds.apache.org/job/PreCommit-PHOENIX-Build/1616//testReport/
Console output: 
https://builds.apache.org/job/PreCommit-PHOENIX-Build/1616//console

This message is automatically generated.

> Surface QueryPlan in MutationPlan
> -
>
> Key: PHOENIX-4342
> URL: https://issues.apache.org/jira/browse/PHOENIX-4342
> Project: Phoenix
>  Issue Type: Improvement
>Reporter: James Taylor
>Assignee: Geoffrey Jacoby
>Priority: Minor
> Attachments: PHOENIX-4342-v2.patch, PHOENIX-4342-v3.patch, 
> PHOENIX-4342-v4.patch, PHOENIX-4342.patch
>
>
> For DELETE statements, it'd be good to be able to get at the QueryPlan 
> through the MutationPlan so we can get more structured information at compile 
> time.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (PHOENIX-4332) Indexes should inherit guide post width of the base data table

2017-11-03 Thread James Taylor (JIRA)


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

James Taylor updated PHOENIX-4332:
--
Fix Version/s: 4.13.0

> Indexes should inherit guide post width of the base data table
> --
>
> Key: PHOENIX-4332
> URL: https://issues.apache.org/jira/browse/PHOENIX-4332
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.12.0
>Reporter: Mujtaba Chohan
>Assignee: Samarth Jain
>Priority: Major
> Fix For: 4.13.0
>
> Attachments: PHOENIX-4332.patch
>
>
> Altering guidepost with on data table does not propagate to global index 
> using {{ALTER TABLE}} command.
> Altering global index table runs in not allowed error.
> {noformat}
> ALTER TABLE IDX SET GUIDE_POSTS_WIDTH=1;
> Error: ERROR 1010 (42M01): Not allowed to mutate table. Cannot add/drop 
> column referenced by VIEW columnName=IDX (state=42M01,code=1010)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (PHOENIX-4332) Indexes should inherit guide post width of the base data table

2017-11-03 Thread James Taylor (JIRA)


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

James Taylor edited comment on PHOENIX-4332 at 11/3/17 10:10 PM:
-

Please remember to set the fix version and mark the issues you fix as resolved, 
[~samarthjain].


was (Author: jamestaylor):
Please remember to mark the issues you fix as resolved, [~samarthjain].

> Indexes should inherit guide post width of the base data table
> --
>
> Key: PHOENIX-4332
> URL: https://issues.apache.org/jira/browse/PHOENIX-4332
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.12.0
>Reporter: Mujtaba Chohan
>Assignee: Samarth Jain
>Priority: Major
> Fix For: 4.13.0
>
> Attachments: PHOENIX-4332.patch
>
>
> Altering guidepost with on data table does not propagate to global index 
> using {{ALTER TABLE}} command.
> Altering global index table runs in not allowed error.
> {noformat}
> ALTER TABLE IDX SET GUIDE_POSTS_WIDTH=1;
> Error: ERROR 1010 (42M01): Not allowed to mutate table. Cannot add/drop 
> column referenced by VIEW columnName=IDX (state=42M01,code=1010)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (PHOENIX-4291) Merge release script for mac and linux

2017-11-03 Thread Hudson (JIRA)


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

Hudson commented on PHOENIX-4291:
-

FAILURE: Integrated in Jenkins build Phoenix-master #1867 (See 
[https://builds.apache.org/job/Phoenix-master/1867/])
PHOENIX-4291 Merge release script for mac and linux (mujtaba: rev 
8f0d546d3d5408283cd29717a67fda2387f737cc)
* (edit) dev/make_rc.sh
* (delete) dev/make_rc_on_mac.sh


> Merge release script for mac and linux
> --
>
> Key: PHOENIX-4291
> URL: https://issues.apache.org/jira/browse/PHOENIX-4291
> Project: Phoenix
>  Issue Type: Improvement
>Affects Versions: 4.12.0
>Reporter: Mujtaba Chohan
>Assignee: Mujtaba Chohan
> Fix For: 4.12.1
>
> Attachments: PHOENIX-4291.patch
>
>
> Merging make_rc.sh and make_rc_on_mac.sh to make_rc_sh. This is based on 
> changes that [~jamestaylor] had in place to execute the script on a Mac.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (PHOENIX-4342) Surface QueryPlan in MutationPlan

2017-11-03 Thread Geoffrey Jacoby (JIRA)


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

Geoffrey Jacoby updated PHOENIX-4342:
-
Attachment: PHOENIX-4342-v4.patch

v4 patch with rebase of PHOENIX-4348

> Surface QueryPlan in MutationPlan
> -
>
> Key: PHOENIX-4342
> URL: https://issues.apache.org/jira/browse/PHOENIX-4342
> Project: Phoenix
>  Issue Type: Improvement
>Reporter: James Taylor
>Assignee: Geoffrey Jacoby
>Priority: Minor
> Attachments: PHOENIX-4342-v2.patch, PHOENIX-4342-v3.patch, 
> PHOENIX-4342-v4.patch, PHOENIX-4342.patch
>
>
> For DELETE statements, it'd be good to be able to get at the QueryPlan 
> through the MutationPlan so we can get more structured information at compile 
> time.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (PHOENIX-4349) Update version to 4.13.0

2017-11-03 Thread Hudson (JIRA)


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

Hudson commented on PHOENIX-4349:
-

FAILURE: Integrated in Jenkins build Phoenix-master #1866 (See 
[https://builds.apache.org/job/Phoenix-master/1866/])
PHOENIX-4349 Update version to 4.13.0 (jtaylor: rev 
79eff5f89adb2c05024272203eebf0504f82ee3d)
* (edit) 
phoenix-core/src/main/java/org/apache/phoenix/coprocessor/MetaDataProtocol.java


> Update version to 4.13.0
> 
>
> Key: PHOENIX-4349
> URL: https://issues.apache.org/jira/browse/PHOENIX-4349
> Project: Phoenix
>  Issue Type: Bug
>Reporter: James Taylor
>Assignee: James Taylor
>Priority: Normal
> Attachments: PHOENIX-4349.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (PHOENIX-4291) Merge release script for mac and linux

2017-11-03 Thread Mujtaba Chohan (JIRA)


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

Mujtaba Chohan resolved PHOENIX-4291.
-
Resolution: Fixed

> Merge release script for mac and linux
> --
>
> Key: PHOENIX-4291
> URL: https://issues.apache.org/jira/browse/PHOENIX-4291
> Project: Phoenix
>  Issue Type: Improvement
>Affects Versions: 4.12.0
>Reporter: Mujtaba Chohan
>Assignee: Mujtaba Chohan
> Fix For: 4.12.1
>
> Attachments: PHOENIX-4291.patch
>
>
> Merging make_rc.sh and make_rc_on_mac.sh to make_rc_sh. This is based on 
> changes that [~jamestaylor] had in place to execute the script on a Mac.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (PHOENIX-4237) Allow sorting on (Java) collation keys for non-English locales

2017-11-03 Thread Hudson (JIRA)


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

Hudson commented on PHOENIX-4237:
-

SUCCESS: Integrated in Jenkins build Phoenix-master #1865 (See 
[https://builds.apache.org/job/Phoenix-master/1865/])
PHOENIX-4237 Allow sorting on (Java) collation keys for non-English (jtaylor: 
rev ee4355791acf3f31568fcd8c43367947d25a1386)
* (add) 
phoenix-core/src/it/java/org/apache/phoenix/end2end/CollationKeyFunctionIT.java
* (edit) 
phoenix-core/src/main/java/org/apache/phoenix/expression/ExpressionType.java
* (add) 
phoenix-core/src/test/java/org/apache/phoenix/expression/function/CollationKeyFunctionTest.java
* (edit) 
phoenix-core/src/main/java/org/apache/phoenix/jdbc/PhoenixConnection.java
* (add) 
phoenix-core/src/main/java/org/apache/phoenix/util/VarBinaryFormatter.java
* (edit) LICENSE
* (edit) phoenix-server/pom.xml
* (add) 
phoenix-core/src/main/java/org/apache/phoenix/expression/function/CollationKeyFunction.java
* (edit) phoenix-core/pom.xml


> Allow sorting on (Java) collation keys for non-English locales
> --
>
> Key: PHOENIX-4237
> URL: https://issues.apache.org/jira/browse/PHOENIX-4237
> Project: Phoenix
>  Issue Type: Improvement
>Reporter: Shehzaad Nakhoda
>Assignee: Shehzaad Nakhoda
>Priority: Major
> Fix For: 4.13.0
>
> Attachments: PHOENIX-4237_v1.patch, PHOENIX-4237_v2.patch, 
> PHOENIX-4237_v3.patch
>
>
> Strings stored via Phoenix can be composed from a subset of the entire set of 
> Unicode characters. The natural sort order for strings for different 
> languages often differs from the order dictated by the binary representation 
> of the characters of these strings. Java provides the idea of a Collator 
> which given an input string and a (language) locale can generate a Collation 
> Key which can then be used to compare strings in that natural order.
> Salesforce has recently open-sourced grammaticus. IBM has open-sourced ICU4J 
> some time ago. These technologies can be combined to provide a robust new 
> Phoenix function that can be used in an ORDER BY clause to sort strings 
> according to the user's locale.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (PHOENIX-3460) Namespace separator ":" should not be allowed in table or schema name

2017-11-03 Thread Thomas D'Silva (JIRA)


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

Thomas D'Silva commented on PHOENIX-3460:
-

OK I see, so should we only disallow creating new tables of the form "a:b" ? 
Even if namespace mapping is disabled , when it creates the hbase table it will 
fail since the namespace "a" doesn't exist.

> Namespace separator ":" should not be allowed in table or schema name
> -
>
> Key: PHOENIX-3460
> URL: https://issues.apache.org/jira/browse/PHOENIX-3460
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.8.0
> Environment: HDP 2.5
>Reporter: Xindian Long
>Assignee: Thomas D'Silva
>Priority: Major
>  Labels: namespaces, phoenix, spark
> Fix For: 4.13.0
>
> Attachments: 0001-Phoenix-fix.patch, PHOENIX-3460-v2.patch, 
> PHOENIX-3460-v2.patch, PHOENIX-3460.patch, SchemaUtil.java
>
>
> I am testing some code using Phoenix Spark plug in to read a Phoenix table 
> with a namespace prefix in the table name (the table is created as a phoenix 
> table not a hbase table), but it returns an TableNotFoundException.
> The table is obviously there because I can query it using plain phoenix sql 
> through Squirrel. In addition, using spark sql to query it has no problem at 
> all.
> I am running on the HDP 2.5 platform, with phoenix 4.7.0.2.5.0.0-1245
> The problem does not exist at all when I was running the same code on HDP 2.4 
> cluster, with phoenix 4.4.
> Neither does the problem occur when I query a table without a namespace 
> prefix in the DB table name, on HDP 2.5
> The log is in the attached file: tableNoFound.txt
> My testing code is also attached.
> The weird thing is in the attached code, if I run testSpark alone it gives 
> the above exception, but if I run the testJdbc first, and followed by 
> testSpark, both of them work.
>  After changing to create table by using
> create table ACME.ENDPOINT_STATUS
> The phoenix-spark plug in seems working. I also find some weird behavior,
> If I do both the following
> create table ACME.ENDPOINT_STATUS ...
> create table "ACME:ENDPOINT_STATUS" ...
> Both table shows up in phoenix, the first one shows as Schema ACME, and table 
> name ENDPOINT_STATUS, and the later on shows as scheme none, and table name 
> ACME:ENDPOINT_STATUS.
> However, in HBASE, I only see one table ACME:ENDPOINT_STATUS. In addition, 
> upserts in the table ACME.ENDPOINT_STATUS show up in the other table, so is 
> the other way around.
>  



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

2017-11-03 Thread Thomas D'Silva (JIRA)


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

Thomas D'Silva commented on PHOENIX-4198:
-

bq. I'm fine, if PHOENIX-672 can keep the users of views, Indexes and data 
table in sync but let's keep this code until PHOENIX-672 is checked-in with 
similar functionality.

OK, sounds good. 

I am +1 on the 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
>Priority: Major
>  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, 
> PHOENIX-4198_v6.patch, PHOENIX-4198_v7.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-3460) Namespace separator ":" should not be allowed in table or schema name

2017-11-03 Thread Thomas D'Silva (JIRA)


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

Thomas D'Silva commented on PHOENIX-3460:
-

Even if namespace mapping is disabled when you do CREATE TABLE "a:b" when it 
tries to create the hbase table it fails (on master). Did this use to work 
before?

> Namespace separator ":" should not be allowed in table or schema name
> -
>
> Key: PHOENIX-3460
> URL: https://issues.apache.org/jira/browse/PHOENIX-3460
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.8.0
> Environment: HDP 2.5
>Reporter: Xindian Long
>Assignee: Thomas D'Silva
>Priority: Major
>  Labels: namespaces, phoenix, spark
> Fix For: 4.13.0
>
> Attachments: 0001-Phoenix-fix.patch, PHOENIX-3460-v2.patch, 
> PHOENIX-3460-v2.patch, PHOENIX-3460.patch, SchemaUtil.java
>
>
> I am testing some code using Phoenix Spark plug in to read a Phoenix table 
> with a namespace prefix in the table name (the table is created as a phoenix 
> table not a hbase table), but it returns an TableNotFoundException.
> The table is obviously there because I can query it using plain phoenix sql 
> through Squirrel. In addition, using spark sql to query it has no problem at 
> all.
> I am running on the HDP 2.5 platform, with phoenix 4.7.0.2.5.0.0-1245
> The problem does not exist at all when I was running the same code on HDP 2.4 
> cluster, with phoenix 4.4.
> Neither does the problem occur when I query a table without a namespace 
> prefix in the DB table name, on HDP 2.5
> The log is in the attached file: tableNoFound.txt
> My testing code is also attached.
> The weird thing is in the attached code, if I run testSpark alone it gives 
> the above exception, but if I run the testJdbc first, and followed by 
> testSpark, both of them work.
>  After changing to create table by using
> create table ACME.ENDPOINT_STATUS
> The phoenix-spark plug in seems working. I also find some weird behavior,
> If I do both the following
> create table ACME.ENDPOINT_STATUS ...
> create table "ACME:ENDPOINT_STATUS" ...
> Both table shows up in phoenix, the first one shows as Schema ACME, and table 
> name ENDPOINT_STATUS, and the later on shows as scheme none, and table name 
> ACME:ENDPOINT_STATUS.
> However, in HBASE, I only see one table ACME:ENDPOINT_STATUS. In addition, 
> upserts in the table ACME.ENDPOINT_STATUS show up in the other table, so is 
> the other way around.
>  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (PHOENIX-4342) Surface QueryPlan in MutationPlan

2017-11-03 Thread Geoffrey Jacoby (JIRA)


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

Geoffrey Jacoby commented on PHOENIX-4342:
--

Merge conflict -- will rebase and get a v4 up soon. 

> Surface QueryPlan in MutationPlan
> -
>
> Key: PHOENIX-4342
> URL: https://issues.apache.org/jira/browse/PHOENIX-4342
> Project: Phoenix
>  Issue Type: Improvement
>Reporter: James Taylor
>Assignee: Geoffrey Jacoby
>Priority: Minor
> Attachments: PHOENIX-4342-v2.patch, PHOENIX-4342-v3.patch, 
> PHOENIX-4342.patch
>
>
> For DELETE statements, it'd be good to be able to get at the QueryPlan 
> through the MutationPlan so we can get more structured information at compile 
> time.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (PHOENIX-4342) Surface QueryPlan in MutationPlan

2017-11-03 Thread Hadoop QA (JIRA)


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

Hadoop QA commented on PHOENIX-4342:


{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12895895/PHOENIX-4342-v3.patch
  against master branch at commit 79eff5f89adb2c05024272203eebf0504f82ee3d.
  ATTACHMENT ID: 12895895

{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 patch{color}.  The patch command could not apply the patch.

Console output: 
https://builds.apache.org/job/PreCommit-PHOENIX-Build/1615//console

This message is automatically generated.

> Surface QueryPlan in MutationPlan
> -
>
> Key: PHOENIX-4342
> URL: https://issues.apache.org/jira/browse/PHOENIX-4342
> Project: Phoenix
>  Issue Type: Improvement
>Reporter: James Taylor
>Assignee: Geoffrey Jacoby
>Priority: Minor
> Attachments: PHOENIX-4342-v2.patch, PHOENIX-4342-v3.patch, 
> PHOENIX-4342.patch
>
>
> For DELETE statements, it'd be good to be able to get at the QueryPlan 
> through the MutationPlan so we can get more structured information at compile 
> time.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (PHOENIX-4288) Indexes not used when ordering by primary key

2017-11-03 Thread Maryann Xue (JIRA)


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

Maryann Xue reassigned PHOENIX-4288:


Assignee: Maryann Xue

> Indexes not used when ordering by primary key
> -
>
> Key: PHOENIX-4288
> URL: https://issues.apache.org/jira/browse/PHOENIX-4288
> Project: Phoenix
>  Issue Type: Sub-task
>Reporter: Marcin Januszkiewicz
>Assignee: Maryann Xue
>Priority: Major
>  Labels: CostBasedOptimization
>
> We have a table
> CREATE TABLE t (
>   rowkey VARCHAR PRIMARY KEY,
>   c1 VARCHAR,
>   c2 VARCHAR
> )
> which we want to query by doing partial matches on c1, and keep the ordering 
> of the source table:
> SELECT rowkey, c1, c2 FROM t where c1 LIKE 'X0%' ORDER BY rowkey;
> We expect most queries to select a small subset of the table, so we create an 
> index to speed up searches:
> CREATE LOCAL INDEX t_c1_ix ON t (c1);
> However, this index will not be used since Phoenix will always choose not to 
> resort the data.
> In our actual use case, adding index hints is not a practical solution.
> See also discussion at:
> https://lists.apache.org/thread.html/26ab58288eb811d2f074c3f89067163d341e5531fb581f3b2486cf43@%3Cuser.phoenix.apache.org%3E



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (PHOENIX-4342) Surface QueryPlan in MutationPlan

2017-11-03 Thread Geoffrey Jacoby (JIRA)


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

Geoffrey Jacoby updated PHOENIX-4342:
-
Attachment: PHOENIX-4342-v3.patch

v3 where the MultiRowDeleteMutationPlan returns the dataPlan as the overall 
QueryPlan. 

> Surface QueryPlan in MutationPlan
> -
>
> Key: PHOENIX-4342
> URL: https://issues.apache.org/jira/browse/PHOENIX-4342
> Project: Phoenix
>  Issue Type: Improvement
>Reporter: James Taylor
>Assignee: Geoffrey Jacoby
>Priority: Minor
> Attachments: PHOENIX-4342-v2.patch, PHOENIX-4342-v3.patch, 
> PHOENIX-4342.patch
>
>
> For DELETE statements, it'd be good to be able to get at the QueryPlan 
> through the MutationPlan so we can get more structured information at compile 
> time.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (PHOENIX-4139) select distinct with identical aggregations return weird values

2017-11-03 Thread James Taylor (JIRA)


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

James Taylor commented on PHOENIX-4139:
---

Sounds like the List we're passing in may not be the correct list, 
[~dumindu] & [~cserba]? The list should be based on what we're doing a GROUP BY 
over (a distinct turns into a GROUP BY). I don't think we'll need to create new 
PDatum objects, but perhaps just the list.

> select distinct with identical aggregations return weird values 
> 
>
> Key: PHOENIX-4139
> URL: https://issues.apache.org/jira/browse/PHOENIX-4139
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.12.0
> Environment: minicluster
>Reporter: Csaba Skrabak
>Assignee: Csaba Skrabak
>Priority: Minor
> Fix For: 4.13.0
>
> Attachments: PHOENIX-4139.patch
>
>
> From sme-hbase hipchat room:
> Pulkit Bhardwaj·10:31
> i'm seeing a weird issue with phoenix, appreciate some thoughts
> Created a simple table in phoenix
> {noformat}
> 0: jdbc:phoenix:> create table test_select(nam VARCHAR(20), address 
> VARCHAR(20), id BIGINT
> . . . . . . . . > constraint my_pk primary key (id));
> 0: jdbc:phoenix:> upsert into test_select (nam, address,id) 
> values('pulkit','badaun',1);
> 0: jdbc:phoenix:> select * from test_select;
> +-+--+-+
> |   NAM   | ADDRESS  | ID  |
> +-+--+-+
> | pulkit  | badaun   | 1   |
> +-+--+-+
> 0: jdbc:phoenix:> select distinct 'harshit' as "test_column", nam from 
> test_select;
> +--+-+
> | test_column  |   NAM   |
> +--+-+
> | harshit  | pulkit  |
> +--+-+
> 0: jdbc:phoenix:> select distinct 'harshit' as "test_column", trim(nam), 
> trim(nam) from test_select;
> +--+++
> | test_column  |   TRIM(NAM)|   TRIM(NAM)|
> +--+++
> | harshit  | pulkitpulkit  | pulkitpulkit  |
> +--+++
> {noformat}
> When I apply a trim on the nam column and use it multiple times, the output 
> has the cell data duplicated!
> {noformat}
> 0: jdbc:phoenix:> select distinct 'harshit' as "test_column", trim(nam), 
> trim(nam), trim(nam) from test_select;
> +--+---+---+---+
> | test_column  |   TRIM(NAM)   |   TRIM(NAM)   |   
> TRIM(NAM)   |
> +--+---+---+---+
> | harshit  | pulkitpulkitpulkit  | pulkitpulkitpulkit  | 
> pulkitpulkitpulkit  |
> +--+---+---+---+
> {noformat}
> Wondering if someone has seen this before??
> One thing to note is, if I remove the —— distinct 'harshit' as "test_column" 
> ——  The issue is not seen
> {noformat}
> 0: jdbc:phoenix:> select trim(nam), trim(nam), trim(nam) from test_select;
> ++++
> | TRIM(NAM)  | TRIM(NAM)  | TRIM(NAM)  |
> ++++
> | pulkit | pulkit | pulkit |
> ++++
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (PHOENIX-4349) Update version to 4.13.0

2017-11-03 Thread James Taylor (JIRA)


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

James Taylor resolved PHOENIX-4349.
---
Resolution: Fixed

> Update version to 4.13.0
> 
>
> Key: PHOENIX-4349
> URL: https://issues.apache.org/jira/browse/PHOENIX-4349
> Project: Phoenix
>  Issue Type: Bug
>Reporter: James Taylor
>Assignee: James Taylor
>Priority: Normal
> Attachments: PHOENIX-4349.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (PHOENIX-4349) Update version to 4.13.0

2017-11-03 Thread James Taylor (JIRA)


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

James Taylor updated PHOENIX-4349:
--
Attachment: PHOENIX-4349.patch

> Update version to 4.13.0
> 
>
> Key: PHOENIX-4349
> URL: https://issues.apache.org/jira/browse/PHOENIX-4349
> Project: Phoenix
>  Issue Type: Bug
>Reporter: James Taylor
>Assignee: James Taylor
>Priority: Normal
> Attachments: PHOENIX-4349.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (PHOENIX-4349) Update version to 4.13.0

2017-11-03 Thread James Taylor (JIRA)

James Taylor created PHOENIX-4349:
-

 Summary: Update version to 4.13.0
 Key: PHOENIX-4349
 URL: https://issues.apache.org/jira/browse/PHOENIX-4349
 Project: Phoenix
  Issue Type: Bug
Reporter: James Taylor
Assignee: James Taylor
Priority: Normal






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (PHOENIX-4237) Allow sorting on (Java) collation keys for non-English locales

2017-11-03 Thread James Taylor (JIRA)


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

James Taylor commented on PHOENIX-4237:
---

+1. Great work, [~shehzaadn]!

> Allow sorting on (Java) collation keys for non-English locales
> --
>
> Key: PHOENIX-4237
> URL: https://issues.apache.org/jira/browse/PHOENIX-4237
> Project: Phoenix
>  Issue Type: Improvement
>Reporter: Shehzaad Nakhoda
>Assignee: Shehzaad Nakhoda
>Priority: Major
> Fix For: 4.12.0
>
> Attachments: PHOENIX-4237_v1.patch, PHOENIX-4237_v2.patch, 
> PHOENIX-4237_v3.patch
>
>
> Strings stored via Phoenix can be composed from a subset of the entire set of 
> Unicode characters. The natural sort order for strings for different 
> languages often differs from the order dictated by the binary representation 
> of the characters of these strings. Java provides the idea of a Collator 
> which given an input string and a (language) locale can generate a Collation 
> Key which can then be used to compare strings in that natural order.
> Salesforce has recently open-sourced grammaticus. IBM has open-sourced ICU4J 
> some time ago. These technologies can be combined to provide a robust new 
> Phoenix function that can be used in an ORDER BY clause to sort strings 
> according to the user's locale.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (PHOENIX-3867) nth_value returns valid values for non-existing rows

2017-11-03 Thread James Taylor (JIRA)


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

James Taylor commented on PHOENIX-3867:
---

Not sure I understand, [~singamteja] - NTH_VALUE returns incorrect results (and 
is used internally by SFDC), yet this is low priority because ???

> nth_value returns valid values for non-existing rows 
> -
>
> Key: PHOENIX-3867
> URL: https://issues.apache.org/jira/browse/PHOENIX-3867
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.10.0
>Reporter: Loknath Priyatham Teja Singamsetty 
>Priority: Major
> Fix For: 4.13.0
>
>
> Assume a table with two rows as follows:
> id, page_id, date, value
> 2, 8 , 1 , 7
> 3, 8 , 2,  9 
> Fetch 3rd most recent value of page_id 3 should not return any values. 
> However, rs.next() succeeds and rs.getInt(1) returns 0 and the assertion 
> fails. Below is the test case depicting the same. 
> Issues:
> 
> a) From sqline, the 3rd nth_value is returned as null
> b) When programatically accessed, it is coming as 0
> Test Case:
> -
> public void nonExistingNthRowTestWithGroupBy() throws Exception {
> Connection conn = DriverManager.getConnection(getUrl());
> String nthValue = generateUniqueName();
> String ddl = "CREATE TABLE IF NOT EXISTS " + nthValue + " "
> + "(id INTEGER NOT NULL PRIMARY KEY, page_id UNSIGNED_LONG,"
> + " dates INTEGER, val INTEGER)";
> conn.createStatement().execute(ddl);
> conn.createStatement().execute(
> "UPSERT INTO " + nthValue + " (id, page_id, dates, val) VALUES 
> (2, 8, 1, 7)");
> conn.createStatement().execute(
> "UPSERT INTO " + nthValue + " (id, page_id, dates, val) VALUES 
> (3, 8, 2, 9)");
> conn.commit();
> ResultSet rs = conn.createStatement().executeQuery(
> "SELECT NTH_VALUE(val, 3) WITHIN GROUP (ORDER BY dates DESC) FROM 
> " + nthValue
> + " GROUP BY page_id");
> assertTrue(rs.next());
> assertEquals(rs.getInt(1), 4);
> assertFalse(rs.next());
> }
> Root Cause:
> ---
> The underlying issue seems to be with the way NTH_Value aggregation is done 
> by the aggregator. The client aggregator is first populated with the top 'n' 
> rows (if present) and during the iterator.next() never gets evaluated in 
> BaseGroupedAggregatingResultIterator to see if the nth row is actually 
> present or not. Once the iterator.next() succeeds, retrieving the value from 
> the result set using the row projector triggers the client aggregators 
> evaluate() method as part of schema.toBytes(..) which is defaulting to 0 for 
> empty row if it is int when programmatically accessed.
>  



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

2017-11-03 Thread Ankit Singhal (JIRA)


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

Ankit Singhal commented on PHOENIX-4198:


bq. In PhoenixAccessController. preCreateTable, for indexes we need 
authorizeOrGrantAccessToUsers() to automatically grant all users/groups who 
have any permissions on the parent table the same permissions on the index 
table. So I think we don't need the isAutomaticGrantEnabled option. 
bq. This change can also be done as part of PHOENIX-672, if you think that 
makes more sense.
I'm fine, if PHOENIX-672 can keep the users of views, Indexes and data table in 
sync but let's keep this code until PHOENIX-672 is checked-in with similar 
functionality.


bq. Related to this, why is automatic grant not allowed for groups?
Just had a thought, that giving an automatic grant to groups could be risky as 
they affect a lot of users, and on the other hand, groups would anyways be easy 
to manage by Admin.


> 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
>Priority: Major
>  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, 
> PHOENIX-4198_v6.patch, PHOENIX-4198_v7.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-3867) nth_value returns valid values for non-existing rows

2017-11-03 Thread Loknath Priyatham Teja Singamsetty (JIRA)


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

Loknath Priyatham Teja Singamsetty  commented on PHOENIX-3867:
--

[~giacomotaylor] This is low priority issue. However in this corner case 
scenario the return output is coming as incorrect data for non-existing row. It 
is nice to fix. Apologies these days occupied with other work.

> nth_value returns valid values for non-existing rows 
> -
>
> Key: PHOENIX-3867
> URL: https://issues.apache.org/jira/browse/PHOENIX-3867
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.10.0
>Reporter: Loknath Priyatham Teja Singamsetty 
>Priority: Major
> Fix For: 4.13.0
>
>
> Assume a table with two rows as follows:
> id, page_id, date, value
> 2, 8 , 1 , 7
> 3, 8 , 2,  9 
> Fetch 3rd most recent value of page_id 3 should not return any values. 
> However, rs.next() succeeds and rs.getInt(1) returns 0 and the assertion 
> fails. Below is the test case depicting the same. 
> Issues:
> 
> a) From sqline, the 3rd nth_value is returned as null
> b) When programatically accessed, it is coming as 0
> Test Case:
> -
> public void nonExistingNthRowTestWithGroupBy() throws Exception {
> Connection conn = DriverManager.getConnection(getUrl());
> String nthValue = generateUniqueName();
> String ddl = "CREATE TABLE IF NOT EXISTS " + nthValue + " "
> + "(id INTEGER NOT NULL PRIMARY KEY, page_id UNSIGNED_LONG,"
> + " dates INTEGER, val INTEGER)";
> conn.createStatement().execute(ddl);
> conn.createStatement().execute(
> "UPSERT INTO " + nthValue + " (id, page_id, dates, val) VALUES 
> (2, 8, 1, 7)");
> conn.createStatement().execute(
> "UPSERT INTO " + nthValue + " (id, page_id, dates, val) VALUES 
> (3, 8, 2, 9)");
> conn.commit();
> ResultSet rs = conn.createStatement().executeQuery(
> "SELECT NTH_VALUE(val, 3) WITHIN GROUP (ORDER BY dates DESC) FROM 
> " + nthValue
> + " GROUP BY page_id");
> assertTrue(rs.next());
> assertEquals(rs.getInt(1), 4);
> assertFalse(rs.next());
> }
> Root Cause:
> ---
> The underlying issue seems to be with the way NTH_Value aggregation is done 
> by the aggregator. The client aggregator is first populated with the top 'n' 
> rows (if present) and during the iterator.next() never gets evaluated in 
> BaseGroupedAggregatingResultIterator to see if the nth row is actually 
> present or not. Once the iterator.next() succeeds, retrieving the value from 
> the result set using the row projector triggers the client aggregators 
> evaluate() method as part of schema.toBytes(..) which is defaulting to 0 for 
> empty row if it is int when programmatically accessed.
>  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (PHOENIX-4237) Allow sorting on (Java) collation keys for non-English locales

2017-11-03 Thread Hadoop QA (JIRA)


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

Hadoop QA commented on PHOENIX-4237:


{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12895584/PHOENIX-4237_v3.patch
  against master branch at commit 1e48eabe4cbf72ce71fb0dbdd6053a9600133ee4.
  ATTACHMENT ID: 12895584

{color:red}-1 @author{color}.  The patch appears to contain 1 @author tags 
which the Hadoop community has agreed to not allow in code contributions.

{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:
+   queryWithCollKeyDefaultArgsWithExpectedOrder("zh_TW", 0, 6, new 
Integer[] { 0, 3, 4, 1, 5, 2, 6 });
+   queryWithCollKeyDefaultArgsWithExpectedOrder("zh_TW_STROKE", 0, 
6, new Integer[] { 4, 2, 0, 3, 1, 6, 5 });
+   queryWithCollKeyDefaultArgsWithExpectedOrder("zh__STROKE", 0, 
6, new Integer[] { 0, 1, 3, 4, 6, 2, 5 });
+   queryWithCollKeyDefaultArgsWithExpectedOrder("zh__PINYIN", 0, 
6, new Integer[] { 0, 1, 3, 4, 6, 2, 5 });
+   queryWithCollKeyUpperCaseWithExpectedOrder("en", 7, 13, new 
Integer[] { 7, 10, 11, 13, 9, 12, 8 });
+   private void queryWithCollKeyDefaultArgsWithExpectedOrder(String 
localeString, Integer beginIndex, Integer endIndex,
+   "SELECT id, data FROM %s WHERE ID BETWEEN %d 
AND %d ORDER BY COLLATION_KEY(data, '%s')", tableName,
+   private void queryWithCollKeyUpperCaseWithExpectedOrder(String 
localeString, Integer beginIndex, Integer endIndex,
+   "SELECT id, data FROM %s WHERE ID BETWEEN %d 
AND %d ORDER BY COLLATION_KEY(data, '%s', true), id",
+   private void queryWithCollKeyWithStrengthWithExpectedOrder(String 
localeString, Integer strength, boolean isDescending,

 {color:red}-1 core tests{color}.  The patch failed these unit tests:
 
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.index.MutableIndexFailureIT

Test results: 
https://builds.apache.org/job/PreCommit-PHOENIX-Build/1614//testReport/
Console output: 
https://builds.apache.org/job/PreCommit-PHOENIX-Build/1614//console

This message is automatically generated.

> Allow sorting on (Java) collation keys for non-English locales
> --
>
> Key: PHOENIX-4237
> URL: https://issues.apache.org/jira/browse/PHOENIX-4237
> Project: Phoenix
>  Issue Type: Improvement
>Reporter: Shehzaad Nakhoda
>Assignee: Shehzaad Nakhoda
>Priority: Major
> Fix For: 4.12.0
>
> Attachments: PHOENIX-4237_v1.patch, PHOENIX-4237_v2.patch, 
> PHOENIX-4237_v3.patch
>
>
> Strings stored via Phoenix can be composed from a subset of the entire set of 
> Unicode characters. The natural sort order for strings for different 
> languages often differs from the order dictated by the binary representation 
> of the characters of these strings. Java provides the idea of a Collator 
> which given an input string and a (language) locale can generate a Collation 
> Key which can then be used to compare strings in that natural order.
> Salesforce has recently open-sourced grammaticus. IBM has open-sourced ICU4J 
> some time ago. These technologies can be combined to provide a robust new 
> Phoenix function that can be used in an ORDER BY clause to sort strings 
> according to the user's locale.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Issue Comment Deleted] (PHOENIX-4237) Allow sorting on (Java) collation keys for non-English locales

2017-11-03 Thread Shehzaad Nakhoda (JIRA)


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

Shehzaad Nakhoda updated PHOENIX-4237:
--
Comment: was deleted

(was: A new patch that removes external code and uses maven dependencies to 
bring in external files.)

> Allow sorting on (Java) collation keys for non-English locales
> --
>
> Key: PHOENIX-4237
> URL: https://issues.apache.org/jira/browse/PHOENIX-4237
> Project: Phoenix
>  Issue Type: Improvement
>Reporter: Shehzaad Nakhoda
>Assignee: Shehzaad Nakhoda
>Priority: Major
> Fix For: 4.12.0
>
> Attachments: PHOENIX-4237_v1.patch, PHOENIX-4237_v2.patch, 
> PHOENIX-4237_v3.patch
>
>
> Strings stored via Phoenix can be composed from a subset of the entire set of 
> Unicode characters. The natural sort order for strings for different 
> languages often differs from the order dictated by the binary representation 
> of the characters of these strings. Java provides the idea of a Collator 
> which given an input string and a (language) locale can generate a Collation 
> Key which can then be used to compare strings in that natural order.
> Salesforce has recently open-sourced grammaticus. IBM has open-sourced ICU4J 
> some time ago. These technologies can be combined to provide a robust new 
> Phoenix function that can be used in an ORDER BY clause to sort strings 
> according to the user's locale.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (PHOENIX-4237) Allow sorting on (Java) collation keys for non-English locales

2017-11-03 Thread Shehzaad Nakhoda (JIRA)


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

Shehzaad Nakhoda updated PHOENIX-4237:
--
Attachment: PHOENIX-4237_v3.patch

A new patch that removes the external com.salesforce and com.ibm code files in 
favor of maven dependencies.

> Allow sorting on (Java) collation keys for non-English locales
> --
>
> Key: PHOENIX-4237
> URL: https://issues.apache.org/jira/browse/PHOENIX-4237
> Project: Phoenix
>  Issue Type: Improvement
>Reporter: Shehzaad Nakhoda
>Assignee: Shehzaad Nakhoda
>Priority: Major
> Fix For: 4.12.0
>
> Attachments: PHOENIX-4237_v1.patch, PHOENIX-4237_v2.patch, 
> PHOENIX-4237_v3.patch
>
>
> Strings stored via Phoenix can be composed from a subset of the entire set of 
> Unicode characters. The natural sort order for strings for different 
> languages often differs from the order dictated by the binary representation 
> of the characters of these strings. Java provides the idea of a Collator 
> which given an input string and a (language) locale can generate a Collation 
> Key which can then be used to compare strings in that natural order.
> Salesforce has recently open-sourced grammaticus. IBM has open-sourced ICU4J 
> some time ago. These technologies can be combined to provide a robust new 
> Phoenix function that can be used in an ORDER BY clause to sort strings 
> according to the user's locale.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (PHOENIX-4237) Allow sorting on (Java) collation keys for non-English locales

2017-11-03 Thread Shehzaad Nakhoda (JIRA)


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

Shehzaad Nakhoda updated PHOENIX-4237:
--
Attachment: PHOENIX-4237.patch_v3

A new patch that removes external code and uses maven dependencies to bring in 
external files.

> Allow sorting on (Java) collation keys for non-English locales
> --
>
> Key: PHOENIX-4237
> URL: https://issues.apache.org/jira/browse/PHOENIX-4237
> Project: Phoenix
>  Issue Type: Improvement
>Reporter: Shehzaad Nakhoda
>Assignee: Shehzaad Nakhoda
>Priority: Major
> Fix For: 4.12.0
>
> Attachments: PHOENIX-4237_v1.patch, PHOENIX-4237_v2.patch
>
>
> Strings stored via Phoenix can be composed from a subset of the entire set of 
> Unicode characters. The natural sort order for strings for different 
> languages often differs from the order dictated by the binary representation 
> of the characters of these strings. Java provides the idea of a Collator 
> which given an input string and a (language) locale can generate a Collation 
> Key which can then be used to compare strings in that natural order.
> Salesforce has recently open-sourced grammaticus. IBM has open-sourced ICU4J 
> some time ago. These technologies can be combined to provide a robust new 
> Phoenix function that can be used in an ORDER BY clause to sort strings 
> according to the user's locale.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (PHOENIX-4237) Allow sorting on (Java) collation keys for non-English locales

2017-11-03 Thread Shehzaad Nakhoda (JIRA)


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

Shehzaad Nakhoda updated PHOENIX-4237:
--
Attachment: (was: PHOENIX-4237.patch_v3)

> Allow sorting on (Java) collation keys for non-English locales
> --
>
> Key: PHOENIX-4237
> URL: https://issues.apache.org/jira/browse/PHOENIX-4237
> Project: Phoenix
>  Issue Type: Improvement
>Reporter: Shehzaad Nakhoda
>Assignee: Shehzaad Nakhoda
>Priority: Major
> Fix For: 4.12.0
>
> Attachments: PHOENIX-4237_v1.patch, PHOENIX-4237_v2.patch
>
>
> Strings stored via Phoenix can be composed from a subset of the entire set of 
> Unicode characters. The natural sort order for strings for different 
> languages often differs from the order dictated by the binary representation 
> of the characters of these strings. Java provides the idea of a Collator 
> which given an input string and a (language) locale can generate a Collation 
> Key which can then be used to compare strings in that natural order.
> Salesforce has recently open-sourced grammaticus. IBM has open-sourced ICU4J 
> some time ago. These technologies can be combined to provide a robust new 
> Phoenix function that can be used in an ORDER BY clause to sort strings 
> according to the user's locale.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (PHOENIX-4328) Support clients having different "phoenix.schema.mapSystemTablesToNamespace" property

2017-11-03 Thread Sergey Soldatov (JIRA)


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

Sergey Soldatov commented on PHOENIX-4328:
--

my 2 cents. I think that migration should be a part of upgrade tool rather than 
running automatically when the first client is connected. And server in 
checkClientServerCompatibiltiy should set the state whether namespace mapping 
is enabled to real state (so if upgrade didn't happen yet,  return false)  but 
not the value that is in the hbase-site.xml. 
As for the retry mechanism on table not found we may call 
checkClientServerCompatibility again as we do for ensureTableCreated. If the 
value has not been changed => fail, otherwise => modify the internal property 
and retry. 

> 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
>Priority: Major
>  Labels: namespaces
> Fix For: 4.13.0
>
>
> 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-4328) Support clients having different "phoenix.schema.mapSystemTablesToNamespace" property

2017-11-03 Thread Karan Mehta (JIRA)


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

Karan Mehta commented on PHOENIX-4328:
--

bq. You can use an instance variable(isNamespaceMappingEnabled) in 
ConnectionQueryServicesImpl which can be set by current logic in 
checkClientServerCompatibility and use it everywhere where the conversion of 
SYSTEM tables names are required?

This can be useful for new clients trying to establish connection. But what 
about the clients already connected? A common retry mechanism needs to be 
established for them. This property is used on server side as well, so the 
solution should be even more generic. Also, the first migration is controlled 
by the client property and I believe that we shouldn't migrate the SYSTEM 
tables to SYSTEM namespace based on server side decision.

bq. we may close https://issues.apache.org/jira/browse/PHOENIX-3288 as 
duplicate if this JIRA is trying to do the same.

What was your motivation behind this JIRA? We may probably end up doing 
something similar but it's not sure.

> 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
>Priority: Major
>  Labels: namespaces
> Fix For: 4.13.0
>
>
> 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-4315) function Greatest/Least

2017-11-03 Thread Ethan Wang (JIRA)


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

Ethan Wang commented on PHOENIX-4315:
-

[~giacomotaylor]

> function Greatest/Least
> ---
>
> Key: PHOENIX-4315
> URL: https://issues.apache.org/jira/browse/PHOENIX-4315
> Project: Phoenix
>  Issue Type: New Feature
>Reporter: Ethan Wang
>Priority: Major
>
> Resolve as the greatest value among a collection of projections.
> e.g.,
> Select greatest(A, B) from table  
> Select greatest(1,2) 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (PHOENIX-4348) Point deletes do not work when there are immutable indexes with only row key columns

2017-11-03 Thread Hudson (JIRA)


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

Hudson commented on PHOENIX-4348:
-

FAILURE: Integrated in Jenkins build Phoenix-master #1864 (See 
[https://builds.apache.org/job/Phoenix-master/1864/])
PHOENIX-4348 Point deletes do not work when there are immutable indexes 
(jtaylor: rev 1e48eabe4cbf72ce71fb0dbdd6053a9600133ee4)
* (edit) 
phoenix-core/src/main/java/org/apache/phoenix/compile/DeleteCompiler.java
* (edit) phoenix-core/src/it/java/org/apache/phoenix/end2end/DeleteIT.java


> Point deletes do not work when there are immutable indexes with only row key 
> columns
> 
>
> Key: PHOENIX-4348
> URL: https://issues.apache.org/jira/browse/PHOENIX-4348
> Project: Phoenix
>  Issue Type: Bug
>Reporter: James Taylor
>Assignee: James Taylor
>Priority: Major
> Fix For: 4.13.0
>
> Attachments: PHOENIX-4348.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

64 matches

Mail list logo