[jira] [Commented] (PHOENIX-4418) UPPER() and LOWER() functions should be locale-aware

2018-03-10 Thread Hudson (JIRA) 

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

Hudson commented on PHOENIX-4418:
-

FAILURE: Integrated in Jenkins build Phoenix-4.x-HBase-0.98 #1828 (See 
[https://builds.apache.org/job/Phoenix-4.x-HBase-0.98/1828/])
PHOENIX-4418 - add locale-awareness to UPPER() and LOWER() functions (tdsilva: 
rev ffb86c12fb203a0edd340e07597bf520d7a0c17f)
* (edit) phoenix-core/src/it/java/org/apache/phoenix/end2end/IndexToolIT.java
* (edit) 
phoenix-core/src/main/java/org/apache/phoenix/expression/function/CollationKeyFunction.java
* (add) 
phoenix-core/src/test/java/org/apache/phoenix/expression/function/LowerFunctionTest.java
* (edit) 
phoenix-core/src/main/java/org/apache/phoenix/expression/function/LowerFunction.java
* (edit) 
phoenix-core/src/main/java/org/apache/phoenix/expression/function/ScalarFunction.java
* (edit) 
phoenix-core/src/it/java/org/apache/phoenix/end2end/IndexExtendedIT.java
* (edit) 
phoenix-core/src/main/java/org/apache/phoenix/expression/function/UpperFunction.java
* (add) 
phoenix-core/src/test/java/org/apache/phoenix/expression/function/UpperFunctionTest.java


> UPPER() and LOWER() functions should be locale-aware
> 
>
> Key: PHOENIX-4418
> URL: https://issues.apache.org/jira/browse/PHOENIX-4418
> Project: Phoenix
>  Issue Type: Improvement
>Affects Versions: 4.13.0
>Reporter: Shehzaad Nakhoda
>Assignee: Shehzaad Nakhoda
>Priority: Major
> Fix For: 4.14.0
>
> Attachments: PHOENIX-4418_v1.patch, PHOENIX-4418_v2.patch, 
> PHOENIX-4418_v3.patch, upper_lower_locale_doc.patch
>
>
> Correct conversion of a string to upper or lower case depends on Locale.
> Java's upper case and lower case conversion routines allow passing in a 
> locale.
> It should be possible to pass in a locale to UPPER() and LOWER() in Phoenix 
> so that locale-specific case conversion can be supported in Phoenix.
> See java.lang.String#toUpperCase()



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (PHOENIX-4634) Looking up a parent index table of a tenant child view fails in BaseColumnResolver createTableRef()

2018-03-10 Thread Thomas D'Silva (JIRA) 

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

Thomas D'Silva commented on PHOENIX-4634:
-

[~jamestaylor] 

I have attached a v5 patch. We have to recursively look up the parent view as 
you could have an index on a  view that has a child view which itself have a 
child view that inherited the index. We have a test for this 
{{ChildViewsUseParentViewIndexIT.testIndexOnParentViewWithTenantSpecificConnection()}}

I changed the updateCacheFrequency of the inherited index to use that of the 
parent table. I also modified the name of the inherited index so that we can 
look up the parent view hierarchy correctly. 

{code}
-PName modifiedIndexName = 
PNameFactory.newName(index.getName().getString() 
-+ QueryConstants.CHILD_VIEW_INDEX_NAME_SEPARATOR + 
view.getName().getString());
+PName modifiedIndexName = 
PNameFactory.newName(view.getName().getString() 
++ QueryConstants.CHILD_VIEW_INDEX_NAME_SEPARATOR + 
index.getName().getString());
{code}

> Looking up a parent index table of a tenant child view fails in 
> BaseColumnResolver createTableRef()
> ---
>
> Key: PHOENIX-4634
> URL: https://issues.apache.org/jira/browse/PHOENIX-4634
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Thomas D'Silva
>Assignee: Thomas D'Silva
>Priority: Major
> Fix For: 4.14.0
>
> Attachments: PHOENIX-4634-4.x-HBase-0.98.patch, 
> PHOENIX-4634-v2.patch, PHOENIX-4634-v3.patch, PHOENIX-4634-v4.patch, 
> PHOENIX-4634-v5.patch
>
>
> If we are looking up a parent table index of a child view , we need to 
> resolve the view which will load the parent table indexes (instead of trying 
> to resolve the parent table index directly). 
>  
> {code:java}
> org.apache.phoenix.schema.TableNotFoundException: ERROR 1012 (42M03): Table 
> undefined. tableName=Schema.Schema.Index#Schma.View
> org.apache.phoenix.compile.FromCompiler$BaseColumnResolver.createTableRef(FromCompiler.java:577)
> at 
> org.apache.phoenix.compile.FromCompiler$SingleTableColumnResolver.(FromCompiler.java:391)
> at 
> org.apache.phoenix.compile.FromCompiler.getResolverForQuery(FromCompiler.java:228)
> at 
> org.apache.phoenix.compile.FromCompiler.getResolverForQuery(FromCompiler.java:206)
> at org.apache.phoenix.optimize.QueryOptimizer.addPlan(QueryOptimizer.java:226)
> at 
> org.apache.phoenix.optimize.QueryOptimizer.getApplicablePlans(QueryOptimizer.java:146)
> at 
> org.apache.phoenix.optimize.QueryOptimizer.getApplicablePlans(QueryOptimizer.java:103)
> at org.apache.phoenix.compile.DeleteCompiler.compile(DeleteCompiler.java:501)
> at 
> org.apache.phoenix.jdbc.PhoenixStatement$ExecutableDeleteStatement.compilePlan(PhoenixStatement.java:770)
> at 
> org.apache.phoenix.jdbc.PhoenixStatement$ExecutableDeleteStatement.compilePlan(PhoenixStatement.java:758)
> at org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:386)
> at org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:376)
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (PHOENIX-4418) UPPER() and LOWER() functions should be locale-aware

2018-03-10 Thread Hudson (JIRA) 

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

Hudson commented on PHOENIX-4418:
-

FAILURE: Integrated in Jenkins build PreCommit-PHOENIX-Build #1799 (See 
[https://builds.apache.org/job/PreCommit-PHOENIX-Build/1799/])
PHOENIX-4418 - add locale-awareness to UPPER() and LOWER() functions (tdsilva: 
rev 759b7c56dafcc6aca5afb11cfb16c723a8a9d366)
* (edit) phoenix-core/src/it/java/org/apache/phoenix/end2end/IndexToolIT.java
* (add) 
phoenix-core/src/test/java/org/apache/phoenix/expression/function/UpperFunctionTest.java
* (edit) 
phoenix-core/src/main/java/org/apache/phoenix/expression/function/UpperFunction.java
* (edit) 
phoenix-core/src/it/java/org/apache/phoenix/end2end/IndexExtendedIT.java
* (edit) 
phoenix-core/src/main/java/org/apache/phoenix/expression/function/ScalarFunction.java
* (edit) 
phoenix-core/src/main/java/org/apache/phoenix/expression/function/CollationKeyFunction.java
* (edit) 
phoenix-core/src/main/java/org/apache/phoenix/expression/function/LowerFunction.java
* (add) 
phoenix-core/src/test/java/org/apache/phoenix/expression/function/LowerFunctionTest.java


> UPPER() and LOWER() functions should be locale-aware
> 
>
> Key: PHOENIX-4418
> URL: https://issues.apache.org/jira/browse/PHOENIX-4418
> Project: Phoenix
>  Issue Type: Improvement
>Affects Versions: 4.13.0
>Reporter: Shehzaad Nakhoda
>Assignee: Shehzaad Nakhoda
>Priority: Major
> Fix For: 4.14.0
>
> Attachments: PHOENIX-4418_v1.patch, PHOENIX-4418_v2.patch, 
> PHOENIX-4418_v3.patch, upper_lower_locale_doc.patch
>
>
> Correct conversion of a string to upper or lower case depends on Locale.
> Java's upper case and lower case conversion routines allow passing in a 
> locale.
> It should be possible to pass in a locale to UPPER() and LOWER() in Phoenix 
> so that locale-specific case conversion can be supported in Phoenix.
> See java.lang.String#toUpperCase()



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (PHOENIX-4634) Looking up a parent index table of a tenant child view fails in BaseColumnResolver createTableRef()

2018-03-10 Thread Thomas D'Silva (JIRA) 

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

Thomas D'Silva updated PHOENIX-4634:

Attachment: PHOENIX-4634-v5.patch

> Looking up a parent index table of a tenant child view fails in 
> BaseColumnResolver createTableRef()
> ---
>
> Key: PHOENIX-4634
> URL: https://issues.apache.org/jira/browse/PHOENIX-4634
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Thomas D'Silva
>Assignee: Thomas D'Silva
>Priority: Major
> Fix For: 4.14.0
>
> Attachments: PHOENIX-4634-4.x-HBase-0.98.patch, 
> PHOENIX-4634-v2.patch, PHOENIX-4634-v3.patch, PHOENIX-4634-v4.patch, 
> PHOENIX-4634-v5.patch
>
>
> If we are looking up a parent table index of a child view , we need to 
> resolve the view which will load the parent table indexes (instead of trying 
> to resolve the parent table index directly). 
>  
> {code:java}
> org.apache.phoenix.schema.TableNotFoundException: ERROR 1012 (42M03): Table 
> undefined. tableName=Schema.Schema.Index#Schma.View
> org.apache.phoenix.compile.FromCompiler$BaseColumnResolver.createTableRef(FromCompiler.java:577)
> at 
> org.apache.phoenix.compile.FromCompiler$SingleTableColumnResolver.(FromCompiler.java:391)
> at 
> org.apache.phoenix.compile.FromCompiler.getResolverForQuery(FromCompiler.java:228)
> at 
> org.apache.phoenix.compile.FromCompiler.getResolverForQuery(FromCompiler.java:206)
> at org.apache.phoenix.optimize.QueryOptimizer.addPlan(QueryOptimizer.java:226)
> at 
> org.apache.phoenix.optimize.QueryOptimizer.getApplicablePlans(QueryOptimizer.java:146)
> at 
> org.apache.phoenix.optimize.QueryOptimizer.getApplicablePlans(QueryOptimizer.java:103)
> at org.apache.phoenix.compile.DeleteCompiler.compile(DeleteCompiler.java:501)
> at 
> org.apache.phoenix.jdbc.PhoenixStatement$ExecutableDeleteStatement.compilePlan(PhoenixStatement.java:770)
> at 
> org.apache.phoenix.jdbc.PhoenixStatement$ExecutableDeleteStatement.compilePlan(PhoenixStatement.java:758)
> at org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:386)
> at org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:376)
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (PHOENIX-4649) Phoenix Upsert..Select query is not working for long running query.But while we ran same query with limit clause then it works fine

2018-03-10 Thread Nitin D Chunke (JIRA) 
Nitin D Chunke created PHOENIX-4649:
---

 Summary: Phoenix Upsert..Select query is not working for long 
running query.But while we ran same query with limit clause then it works fine  
 Key: PHOENIX-4649
 URL: https://issues.apache.org/jira/browse/PHOENIX-4649
 Project: Phoenix
  Issue Type: Bug
Affects Versions: 4.11.0
Reporter: Nitin D Chunke
 Fix For: 5.0.0-alpha
 Attachments: image-2018-03-11-00-16-14-968.png, 
image-2018-03-11-00-22-32-613.png

We have data in table A which is around 3 Million Records. and from this table 
we have upsert data in to table B with out limit clause.

(Note : Here we already export the hbase conf path and set all phoenix 
properties to mentioned value and both the tables are salted)

Please find following hbase-site.xml screen shot.

!image-2018-03-11-00-22-32-613.png!

But hbase conf was not picked up when we launch sqlline/psql.

Please refer following screenshot 

!image-2018-03-11-00-16-14-968.png!

And when we ran same query with setting limit clause which is higher than total 
number record present in table A,it runs absolutely fine with out giving any 
error. 

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Expanding Phoenix support to additional versions of CDH

2018-03-10 Thread Pedro Boado 
I rather prefer keeping several branches. Most of the changes in our cdh
branch are related to a couple of interfaces in HBase 1.2-cdh that have
included changes from Apache HBase 1.3 (as Apache HBase 1.2 is close to
EOM, Cloudera keeps patching it's versions by applying some changes from
HBase 1.3) and that Phoenix implements. Shim layer would make thing more
complicated.

It's quite likely that the only change needed is at pom.xml level ( cdh
version-specific grandparent pom and related properties in parent pom )

This could be solved by keeping our current 4.x-cdh-5.11.2 in sync (
renamed as 4.x-cdh5 ) with 4.x-HBase-1.2, and then keep rebasing supported
version branches 4.x-cdh-5.11.2, 4.x-cdh-5.13.2, etc  onto 4.x-cdh5 ~HEAD.



On 10 Mar 2018 05:36, "James Taylor"  wrote:

> If you're willing to sign up to keep the CDH branches in sync with the
> 4.x-HBase-1.2 branches, then that seems fine. Should we look into some kind
> of automation for syncing all the branches?
>
> Another approach is a shim layer, but we've been reluctant to set that up
> as there's a fair amount of initial overhead to implement.
>
> On Thu, Mar 8, 2018 at 4:24 PM, Pedro Boado  wrote:
>
> > Hi all,
> >
> > After our first release of Phoenix for CDH 5.11.2 it looks like a good
> idea
> > expanding support to other newer versions. I'd like to discuss with you
> > guys what would be the best approach as we have several options:
> >
> > - Releasing one single generated parcel with wider compatibility (
> > cloudera-labs phoenix style ) . The issue here is that all transitive
> > dependencies packaged in phoenix fatjars would be specific to a cdh
> version
> > (let's say, cdh5.11.2) but would be running against different cdh version
> > (maybe cdh5.14.0 ) . There is a small chance of incompatibility across
> > versions ( even when all of them are HBase 1.2 based ) . Also we wouldn't
> > be running our IT against all these cdh versions.
> >
> > - Maybe work further into packaging (and removing) any dependency that is
> > already shipped in cdh. That would improve compatibility of this unique
> > parcel version across cdh releases. But fat client fatjars would still
> be a
> > problem for use from out of hadoop cluster.
> >
> > - Release several parcels specific to different cdh versions ( my
> favourite
> > option ) . That is the safest option for better compatibility as we would
> > be shipping the exact same libraries in the parcel as used in that
> version
> > of cdh. And we'd also be doing IT for several cdh versions. Downside is a
> > little bit more of release effort ( not a big deal ) , more branches in
> git
> > and  more web server space needed for keeping several parcels ( I'm not
> > sure if that is an issue )
> >
> > All ideas are welcome.
> >
> > Thanks!
> >
>