[jira] [Updated] (PHOENIX-4616) Move join query optimization out from QueryCompiler into QueryOptimizer

2018-02-23 Thread Maryann Xue (JIRA) 

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

Maryann Xue updated PHOENIX-4616:
-
Attachment: PHOENIX-4616.patch

> Move join query optimization out from QueryCompiler into QueryOptimizer
> ---
>
> Key: PHOENIX-4616
> URL: https://issues.apache.org/jira/browse/PHOENIX-4616
> Project: Phoenix
>  Issue Type: Improvement
>Reporter: Maryann Xue
>Assignee: Maryann Xue
>Priority: Major
> Attachments: PHOENIX-4616.patch
>
>
> Currently we do optimization for join queries inside QueryCompiler, which 
> makes the APIs and code logic confusing, so we need to move join optimization 
> logic into QueryOptimizer.
>  Similarly, but probably with a different approach, we need to optimize UNION 
> ALL queries and derived table sub-queries in QueryOptimizer.optimize().
> Please also refer to this comment:
> https://issues.apache.org/jira/browse/PHOENIX-4585?focusedCommentId=16367616=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16367616



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

[jira] [Updated] (PHOENIX-4616) Move join query optimization out from QueryCompiler into QueryOptimizer

2018-02-23 Thread Maryann Xue (JIRA) 

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

Maryann Xue updated PHOENIX-4616:
-
Attachment: (was: PHOENIX-4616.patch)

> Move join query optimization out from QueryCompiler into QueryOptimizer
> ---
>
> Key: PHOENIX-4616
> URL: https://issues.apache.org/jira/browse/PHOENIX-4616
> Project: Phoenix
>  Issue Type: Improvement
>Reporter: Maryann Xue
>Assignee: Maryann Xue
>Priority: Major
> Attachments: PHOENIX-4616.patch
>
>
> Currently we do optimization for join queries inside QueryCompiler, which 
> makes the APIs and code logic confusing, so we need to move join optimization 
> logic into QueryOptimizer.
>  Similarly, but probably with a different approach, we need to optimize UNION 
> ALL queries and derived table sub-queries in QueryOptimizer.optimize().
> Please also refer to this comment:
> https://issues.apache.org/jira/browse/PHOENIX-4585?focusedCommentId=16367616=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16367616



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

[jira] [Commented] (PHOENIX-1890) Provide queries for adding/deleting jars to/from common place in hdfs which is used by dynamic class loader

2018-02-23 Thread Ethan Wang (JIRA) 

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

Ethan Wang commented on PHOENIX-1890:
-

Great work!

PS. I couldn't find documentation for this one. Do we have some grammar 
instruction somewhere already?

> Provide queries for adding/deleting jars to/from common place in hdfs which 
> is used by dynamic class loader
> ---
>
> Key: PHOENIX-1890
> URL: https://issues.apache.org/jira/browse/PHOENIX-1890
> Project: Phoenix
>  Issue Type: Sub-task
>Reporter: Rajeshbabu Chintaguntla
>Assignee: Rajeshbabu Chintaguntla
>Priority: Major
> Fix For: 4.5.0
>
> Attachments: PHOENIX-1890.patch
>
>




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

[jira] [Updated] (PHOENIX-4616) Move join query optimization out from QueryCompiler into QueryOptimizer

2018-02-23 Thread Maryann Xue (JIRA) 

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

Maryann Xue updated PHOENIX-4616:
-
Attachment: PHOENIX-4616.patch

> Move join query optimization out from QueryCompiler into QueryOptimizer
> ---
>
> Key: PHOENIX-4616
> URL: https://issues.apache.org/jira/browse/PHOENIX-4616
> Project: Phoenix
>  Issue Type: Improvement
>Reporter: Maryann Xue
>Assignee: Maryann Xue
>Priority: Major
> Attachments: PHOENIX-4616.patch
>
>
> Currently we do optimization for join queries inside QueryCompiler, which 
> makes the APIs and code logic confusing, so we need to move join optimization 
> logic into QueryOptimizer.
>  Similarly, but probably with a different approach, we need to optimize UNION 
> ALL queries and derived table sub-queries in QueryOptimizer.optimize().
> Please also refer to this comment:
> https://issues.apache.org/jira/browse/PHOENIX-4585?focusedCommentId=16367616=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16367616



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

[GitHub] phoenix pull request #292: PHOENIX-4231: Support restriction of remote UDF l...

2018-02-23 Thread aertoria 
Github user aertoria commented on a diff in the pull request:

https://github.com/apache/phoenix/pull/292#discussion_r170387933
  
--- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/expression/function/UDFExpression.java
 ---
@@ -198,18 +199,26 @@ public static DynamicClassLoader getClassLoader(final 
PName tenantId, final Stri
 }
 return cl;
 } else {
-cl = pathSpecificCls.get(jarPath);
-if (cl == null) {
-Configuration conf = HBaseConfiguration.create(config);
-conf.set(DYNAMIC_JARS_DIR_KEY, parent);
-cl = new DynamicClassLoader(conf, 
UDFExpression.class.getClassLoader());
-}
-// Cache class loader as a weak value, will be GC'ed when no 
reference left
-DynamicClassLoader prev = pathSpecificCls.putIfAbsent(jarPath, 
cl);
-if (prev != null) {
-cl = prev;
+String rawPath = new 
Path(config.get(DYNAMIC_JARS_DIR_KEY)).toUri().getRawPath();
+// jarPath is provided as an HDFS URI without scheme and 
authority, but the jar is inside the configured hbase.dynamic.jars.dir
+if(rawPath.equals(parent)) {
--- End diff --

This if block seems will never be reachable. See line 188.  Aren't these 
two condition equivalent?


---

[jira] [Commented] (PHOENIX-4231) Support restriction of remote UDF load sources

2018-02-23 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on PHOENIX-4231:
-

Github user aertoria commented on a diff in the pull request:

https://github.com/apache/phoenix/pull/292#discussion_r170387933
  
--- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/expression/function/UDFExpression.java
 ---
@@ -198,18 +199,26 @@ public static DynamicClassLoader getClassLoader(final 
PName tenantId, final Stri
 }
 return cl;
 } else {
-cl = pathSpecificCls.get(jarPath);
-if (cl == null) {
-Configuration conf = HBaseConfiguration.create(config);
-conf.set(DYNAMIC_JARS_DIR_KEY, parent);
-cl = new DynamicClassLoader(conf, 
UDFExpression.class.getClassLoader());
-}
-// Cache class loader as a weak value, will be GC'ed when no 
reference left
-DynamicClassLoader prev = pathSpecificCls.putIfAbsent(jarPath, 
cl);
-if (prev != null) {
-cl = prev;
+String rawPath = new 
Path(config.get(DYNAMIC_JARS_DIR_KEY)).toUri().getRawPath();
+// jarPath is provided as an HDFS URI without scheme and 
authority, but the jar is inside the configured hbase.dynamic.jars.dir
+if(rawPath.equals(parent)) {
--- End diff --

This if block seems will never be reachable. See line 188.  Aren't these 
two condition equivalent?


> Support restriction of remote UDF load sources 
> ---
>
> Key: PHOENIX-4231
> URL: https://issues.apache.org/jira/browse/PHOENIX-4231
> Project: Phoenix
>  Issue Type: Improvement
>Reporter: Andrew Purtell
>Assignee: Chinmay Kulkarni
>Priority: Major
>
> When allowUserDefinedFunctions is true, users can load UDFs remotely via a 
> jar file from any HDFS filesystem reachable on the network. The setting 
> hbase.dynamic.jars.dir can be used to restrict locations for jar loading but 
> is only applied to jars loaded from the local filesystem.  We should 
> implement support for similar restriction via configuration for jars loaded 
> via hdfs:// URIs.



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

[jira] [Comment Edited] (PHOENIX-4361) Remove redundant argument in separateAndValidateProperties in CQSI

2018-02-23 Thread Ethan Wang (JIRA) 

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

Ethan Wang edited comment on PHOENIX-4361 at 2/23/18 9:19 PM:
--

[~rajeshbabu]

This JIRA also need to be back ported to 5.x-hbase-2.0. Just Done. FYI


was (Author: aertoria):
 

[~rajeshbabu]

This JIRA also need to be back ported to 5.x-hbase-2.0. Just Done. FYI

> Remove redundant argument in separateAndValidateProperties in CQSI
> --
>
> Key: PHOENIX-4361
> URL: https://issues.apache.org/jira/browse/PHOENIX-4361
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Ethan Wang
>Assignee: Chinmay Kulkarni
>Priority: Minor
>
> Remove redundant argument in separateAndValidateProperties in CQSI
> private Pair 
> separateAndValidateProperties(PTable table, Map Object>>> properties, Set colFamiliesForPColumnsToBeAdded, 
> List>> families, Map 
> tableProps) 
> Map>> families was never used.



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

[jira] [Commented] (PHOENIX-4361) Remove redundant argument in separateAndValidateProperties in CQSI

2018-02-23 Thread Ethan Wang (JIRA) 

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

Ethan Wang commented on PHOENIX-4361:
-

 

[~rajeshbabu]

This JIRA also need to be back ported to 5.x-hbase-2.0. Just Done. FYI

> Remove redundant argument in separateAndValidateProperties in CQSI
> --
>
> Key: PHOENIX-4361
> URL: https://issues.apache.org/jira/browse/PHOENIX-4361
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Ethan Wang
>Assignee: Chinmay Kulkarni
>Priority: Minor
>
> Remove redundant argument in separateAndValidateProperties in CQSI
> private Pair 
> separateAndValidateProperties(PTable table, Map Object>>> properties, Set colFamiliesForPColumnsToBeAdded, 
> List>> families, Map 
> tableProps) 
> Map>> families was never used.



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

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

2018-02-23 Thread Ethan Wang (JIRA) 

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

Ethan Wang commented on PHOENIX-3837:
-

[~rajeshbabu]

Done. Just cherry-picked the patch to 5.x-HBase-2.0.

Note:

1, This patch PHOENIX-3837 requires PHOENIX-4361, so I also cherry picked 
PHOENIX-4361

2, This patch PHOENIX-3837 also requires PHOENIX-2566, part of it has not been 
committed to this branch. I did that too.

3, Hbase2.0 replaces TableDescriptor with HTableDescriptor. So I updated with 
TableDescriptor in my patch

> 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, 5.0.0
>
> Attachments: PHOENIX-3837-Merged_With_5.x-2.0-and-Master.patch, 
> PHOENIX-3837.patch
>
>
> {{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
(v7.6.3#76005)

[jira] [Commented] (PHOENIX-4424) Allow users to create "DEFAULT" and "HBASE" Schema (Uppercase Schema Names)

2018-02-23 Thread Rajeshbabu Chintaguntla (JIRA) 

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

Rajeshbabu Chintaguntla commented on PHOENIX-4424:
--

Here is patch for 5.x branch. It's not full patch. ChangePermissionsIT need to 
be added as part of PHOENIX-672. 

> Allow users to create "DEFAULT" and "HBASE" Schema (Uppercase Schema Names)
> ---
>
> Key: PHOENIX-4424
> URL: https://issues.apache.org/jira/browse/PHOENIX-4424
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Karan Mehta
>Assignee: Karan Mehta
>Priority: Major
> Fix For: 4.14.0
>
> Attachments: PHOENIX-4424.001.patch, PHOENIX-4424.002.patch, 
> PHOENIX-4424_5.x-HBase-2.0.patch
>
>
> We currently block users to create "DEFAULT" and "HBASE" schema, however it 
> should be actually "default" and "hbase" since hbase namespace is case 
> sensitive. Hence we should update it and allow is users want to create 
> schema's with those names.
> If user wants to access the schema names with capital letters, they can pass 
> it in directly (Phoenix will automatically upper-case it) or pass it in 
> uppercase letters with double-quotes.
> FYI.
> [~twdsi...@gmail.com]



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

[jira] [Updated] (PHOENIX-4424) Allow users to create "DEFAULT" and "HBASE" Schema (Uppercase Schema Names)

2018-02-23 Thread Rajeshbabu Chintaguntla (JIRA) 

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

Rajeshbabu Chintaguntla updated PHOENIX-4424:
-
Attachment: PHOENIX-4424_5.x-HBase-2.0.patch

> Allow users to create "DEFAULT" and "HBASE" Schema (Uppercase Schema Names)
> ---
>
> Key: PHOENIX-4424
> URL: https://issues.apache.org/jira/browse/PHOENIX-4424
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Karan Mehta
>Assignee: Karan Mehta
>Priority: Major
> Fix For: 4.14.0
>
> Attachments: PHOENIX-4424.001.patch, PHOENIX-4424.002.patch, 
> PHOENIX-4424_5.x-HBase-2.0.patch
>
>
> We currently block users to create "DEFAULT" and "HBASE" schema, however it 
> should be actually "default" and "hbase" since hbase namespace is case 
> sensitive. Hence we should update it and allow is users want to create 
> schema's with those names.
> If user wants to access the schema names with capital letters, they can pass 
> it in directly (Phoenix will automatically upper-case it) or pass it in 
> uppercase letters with double-quotes.
> FYI.
> [~twdsi...@gmail.com]



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

[jira] [Commented] (PHOENIX-4488) Cache config parameters for MetaDataEndPointImpl during initialization

2018-02-23 Thread Rajeshbabu Chintaguntla (JIRA) 

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

Rajeshbabu Chintaguntla commented on PHOENIX-4488:
--

Pushed it to 5.x branch.

> Cache config parameters for MetaDataEndPointImpl during initialization
> --
>
> Key: PHOENIX-4488
> URL: https://issues.apache.org/jira/browse/PHOENIX-4488
> Project: Phoenix
>  Issue Type: Bug
>Reporter: James Taylor
>Assignee: James Taylor
>Priority: Major
> Fix For: 4.14.0, 5.0.0
>
> Attachments: PHOENIX-4488.patch, PHOENIX-4488_5.x-HBase-2.0.patch
>
>
> For example, see this code (which is called often):
> {code}
> boolean blockWriteRebuildIndex = 
> env.getConfiguration().getBoolean(QueryServices.INDEX_FAILURE_BLOCK_WRITE, 
> QueryServicesOptions.DEFAULT_INDEX_FAILURE_BLOCK_WRITE);
> {code}



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

[jira] [Updated] (PHOENIX-4488) Cache config parameters for MetaDataEndPointImpl during initialization

2018-02-23 Thread Rajeshbabu Chintaguntla (JIRA) 

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

Rajeshbabu Chintaguntla updated PHOENIX-4488:
-
Fix Version/s: 5.0.0

> Cache config parameters for MetaDataEndPointImpl during initialization
> --
>
> Key: PHOENIX-4488
> URL: https://issues.apache.org/jira/browse/PHOENIX-4488
> Project: Phoenix
>  Issue Type: Bug
>Reporter: James Taylor
>Assignee: James Taylor
>Priority: Major
> Fix For: 4.14.0, 5.0.0
>
> Attachments: PHOENIX-4488.patch, PHOENIX-4488_5.x-HBase-2.0.patch
>
>
> For example, see this code (which is called often):
> {code}
> boolean blockWriteRebuildIndex = 
> env.getConfiguration().getBoolean(QueryServices.INDEX_FAILURE_BLOCK_WRITE, 
> QueryServicesOptions.DEFAULT_INDEX_FAILURE_BLOCK_WRITE);
> {code}



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

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

2018-02-23 Thread Rajeshbabu Chintaguntla (JIRA) 

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

Rajeshbabu Chintaguntla updated PHOENIX-3837:
-
Fix Version/s: 5.0.0

> 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, 5.0.0
>
> Attachments: PHOENIX-3837-Merged_With_5.x-2.0-and-Master.patch, 
> PHOENIX-3837.patch
>
>
> {{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
(v7.6.3#76005)

[jira] [Updated] (PHOENIX-4488) Cache config parameters for MetaDataEndPointImpl during initialization

2018-02-23 Thread Rajeshbabu Chintaguntla (JIRA) 

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

Rajeshbabu Chintaguntla updated PHOENIX-4488:
-
Attachment: PHOENIX-4488_5.x-HBase-2.0.patch

> Cache config parameters for MetaDataEndPointImpl during initialization
> --
>
> Key: PHOENIX-4488
> URL: https://issues.apache.org/jira/browse/PHOENIX-4488
> Project: Phoenix
>  Issue Type: Bug
>Reporter: James Taylor
>Assignee: James Taylor
>Priority: Major
> Fix For: 4.14.0
>
> Attachments: PHOENIX-4488.patch, PHOENIX-4488_5.x-HBase-2.0.patch
>
>
> For example, see this code (which is called often):
> {code}
> boolean blockWriteRebuildIndex = 
> env.getConfiguration().getBoolean(QueryServices.INDEX_FAILURE_BLOCK_WRITE, 
> QueryServicesOptions.DEFAULT_INDEX_FAILURE_BLOCK_WRITE);
> {code}



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

[jira] [Commented] (PHOENIX-4487) Missing SYSTEM.MUTEX table upgrading from 4.7 to 4.13

2018-02-23 Thread Rajeshbabu Chintaguntla (JIRA) 

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

Rajeshbabu Chintaguntla commented on PHOENIX-4487:
--

Pushed this to 5.x branch.

> Missing SYSTEM.MUTEX table upgrading from 4.7 to 4.13
> -
>
> Key: PHOENIX-4487
> URL: https://issues.apache.org/jira/browse/PHOENIX-4487
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.14.0, 4.13.1, 4.13.2-cdh5.11.2
>Reporter: Flavio Pompermaier
>Assignee: James Taylor
>Priority: Major
> Fix For: 4.14.0, 4.13.2-cdh5.11.2, 5.0.0
>
> Attachments: PHOENIX-4487.patch, PHOENIX-4487_5.x-HBase-2.0.patch, 
> PHOENIX-4487_v2.patch
>
>
> Upgrading from the official Cloudera Parcel equipped with Phoenix 4.7  to the 
> last unofficial parcel (4.13 on CDH 5.11.2) I had the same error of 
> https://issues.apache.org/jira/browse/PHOENIX-4293 (apart from the fact that 
> the from version was 4.7...).
> The creation of system.mutex table fixed the problem.



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

[jira] [Updated] (PHOENIX-4487) Missing SYSTEM.MUTEX table upgrading from 4.7 to 4.13

2018-02-23 Thread Rajeshbabu Chintaguntla (JIRA) 

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

Rajeshbabu Chintaguntla updated PHOENIX-4487:
-
Fix Version/s: 5.0.0

> Missing SYSTEM.MUTEX table upgrading from 4.7 to 4.13
> -
>
> Key: PHOENIX-4487
> URL: https://issues.apache.org/jira/browse/PHOENIX-4487
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.14.0, 4.13.1, 4.13.2-cdh5.11.2
>Reporter: Flavio Pompermaier
>Assignee: James Taylor
>Priority: Major
> Fix For: 4.14.0, 4.13.2-cdh5.11.2, 5.0.0
>
> Attachments: PHOENIX-4487.patch, PHOENIX-4487_5.x-HBase-2.0.patch, 
> PHOENIX-4487_v2.patch
>
>
> Upgrading from the official Cloudera Parcel equipped with Phoenix 4.7  to the 
> last unofficial parcel (4.13 on CDH 5.11.2) I had the same error of 
> https://issues.apache.org/jira/browse/PHOENIX-4293 (apart from the fact that 
> the from version was 4.7...).
> The creation of system.mutex table fixed the problem.



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

[jira] [Updated] (PHOENIX-4487) Missing SYSTEM.MUTEX table upgrading from 4.7 to 4.13

2018-02-23 Thread Rajeshbabu Chintaguntla (JIRA) 

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

Rajeshbabu Chintaguntla updated PHOENIX-4487:
-
Attachment: PHOENIX-4487_5.x-HBase-2.0.patch

> Missing SYSTEM.MUTEX table upgrading from 4.7 to 4.13
> -
>
> Key: PHOENIX-4487
> URL: https://issues.apache.org/jira/browse/PHOENIX-4487
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.14.0, 4.13.1, 4.13.2-cdh5.11.2
>Reporter: Flavio Pompermaier
>Assignee: James Taylor
>Priority: Major
> Fix For: 4.14.0, 4.13.2-cdh5.11.2
>
> Attachments: PHOENIX-4487.patch, PHOENIX-4487_5.x-HBase-2.0.patch, 
> PHOENIX-4487_v2.patch
>
>
> Upgrading from the official Cloudera Parcel equipped with Phoenix 4.7  to the 
> last unofficial parcel (4.13 on CDH 5.11.2) I had the same error of 
> https://issues.apache.org/jira/browse/PHOENIX-4293 (apart from the fact that 
> the from version was 4.7...).
> The creation of system.mutex table fixed the problem.



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

[jira] [Updated] (PHOENIX-4278) Implement pure client side transactional index maintenance

2018-02-23 Thread Rajeshbabu Chintaguntla (JIRA) 

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

Rajeshbabu Chintaguntla updated PHOENIX-4278:
-
Fix Version/s: 5.0.0

> Implement pure client side transactional index maintenance
> --
>
> Key: PHOENIX-4278
> URL: https://issues.apache.org/jira/browse/PHOENIX-4278
> Project: Phoenix
>  Issue Type: Improvement
>Reporter: James Taylor
>Assignee: Ohad Shacham
>Priority: Major
> Fix For: 4.14.0, 5.0.0
>
> Attachments: PHOENIX-4278.4.x-HBase-1.3.v1.patch, 
> PHOENIX-4278_5.x-HBase-2.0.patch, PHOENIX-4278_v2.patch
>
>
> The index maintenance for transactions follows the same model as non 
> transactional tables - coprocessor based on data table updates that looks up 
> previous row value to perform maintenance. This is necessary for non 
> transactional tables to ensure the rows are locked so that a consistent view 
> may be obtained. However, for transactional tables, the time stamp oracle 
> ensures uniqueness of time stamps (via transaction IDs) and the filtering 
> handles a scan seeing the "true" last committed value for a row. Thus, 
> there's no hard dependency to perform this on the server side.
> Moving the index maintenance to the client side would prevent any RS->RS RPC 
> calls (which have proved to be troublesome for HBase). It would require 
> returning more data to the client (i.e. the prior row value), but this seems 
> like a reasonable tradeoff.



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

[jira] [Commented] (PHOENIX-4610) Converge 4.x and 5.x branches

2018-02-23 Thread Rajeshbabu Chintaguntla (JIRA) 

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

Rajeshbabu Chintaguntla commented on PHOENIX-4610:
--

[~jamestaylor]
I will merge once this sync up work is done. Thanks

> Converge 4.x and 5.x branches
> -
>
> Key: PHOENIX-4610
> URL: https://issues.apache.org/jira/browse/PHOENIX-4610
> Project: Phoenix
>  Issue Type: Task
>Reporter: Josh Elser
>Assignee: Rajeshbabu Chintaguntla
>Priority: Major
> Fix For: 5.0.0
>
>
> We have a quite a few improvements which have landed on the 4.x branches 
> which have missed the 5.x branch due to its earlier instability. Rajeshbabu 
> volunteered offline to me to start this onerous task.



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

[jira] [Commented] (PHOENIX-4278) Implement pure client side transactional index maintenance

2018-02-23 Thread Rajeshbabu Chintaguntla (JIRA) 

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

Rajeshbabu Chintaguntla commented on PHOENIX-4278:
--

[~jamestaylor] [~ohads] here is the patch for 5.x branch going to commit.

> Implement pure client side transactional index maintenance
> --
>
> Key: PHOENIX-4278
> URL: https://issues.apache.org/jira/browse/PHOENIX-4278
> Project: Phoenix
>  Issue Type: Improvement
>Reporter: James Taylor
>Assignee: Ohad Shacham
>Priority: Major
> Fix For: 4.14.0
>
> Attachments: PHOENIX-4278.4.x-HBase-1.3.v1.patch, 
> PHOENIX-4278_5.x-HBase-2.0.patch, PHOENIX-4278_v2.patch
>
>
> The index maintenance for transactions follows the same model as non 
> transactional tables - coprocessor based on data table updates that looks up 
> previous row value to perform maintenance. This is necessary for non 
> transactional tables to ensure the rows are locked so that a consistent view 
> may be obtained. However, for transactional tables, the time stamp oracle 
> ensures uniqueness of time stamps (via transaction IDs) and the filtering 
> handles a scan seeing the "true" last committed value for a row. Thus, 
> there's no hard dependency to perform this on the server side.
> Moving the index maintenance to the client side would prevent any RS->RS RPC 
> calls (which have proved to be troublesome for HBase). It would require 
> returning more data to the client (i.e. the prior row value), but this seems 
> like a reasonable tradeoff.



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

[jira] [Updated] (PHOENIX-4278) Implement pure client side transactional index maintenance

2018-02-23 Thread Rajeshbabu Chintaguntla (JIRA) 

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

Rajeshbabu Chintaguntla updated PHOENIX-4278:
-
Attachment: PHOENIX-4278_5.x-HBase-2.0.patch

> Implement pure client side transactional index maintenance
> --
>
> Key: PHOENIX-4278
> URL: https://issues.apache.org/jira/browse/PHOENIX-4278
> Project: Phoenix
>  Issue Type: Improvement
>Reporter: James Taylor
>Assignee: Ohad Shacham
>Priority: Major
> Fix For: 4.14.0
>
> Attachments: PHOENIX-4278.4.x-HBase-1.3.v1.patch, 
> PHOENIX-4278_5.x-HBase-2.0.patch, PHOENIX-4278_v2.patch
>
>
> The index maintenance for transactions follows the same model as non 
> transactional tables - coprocessor based on data table updates that looks up 
> previous row value to perform maintenance. This is necessary for non 
> transactional tables to ensure the rows are locked so that a consistent view 
> may be obtained. However, for transactional tables, the time stamp oracle 
> ensures uniqueness of time stamps (via transaction IDs) and the filtering 
> handles a scan seeing the "true" last committed value for a row. Thus, 
> there's no hard dependency to perform this on the server side.
> Moving the index maintenance to the client side would prevent any RS->RS RPC 
> calls (which have proved to be troublesome for HBase). It would require 
> returning more data to the client (i.e. the prior row value), but this seems 
> like a reasonable tradeoff.



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

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

2018-02-23 Thread Rajeshbabu Chintaguntla (JIRA) 

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

Rajeshbabu Chintaguntla updated PHOENIX-4288:
-
Fix Version/s: 5.0.0

> 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
> Fix For: 4.14.0, 5.0.0
>
> Attachments: PHOENIX-4288.patch
>
>
> 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
(v7.6.3#76005)

[jira] [Updated] (PHOENIX-4322) DESC primary key column with variable length does not work in SkipScanFilter

2018-02-23 Thread Rajeshbabu Chintaguntla (JIRA) 

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

Rajeshbabu Chintaguntla updated PHOENIX-4322:
-
Fix Version/s: 5.0.0

> DESC primary key column with variable length does not work in SkipScanFilter
> 
>
> Key: PHOENIX-4322
> URL: https://issues.apache.org/jira/browse/PHOENIX-4322
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.11.0
>Reporter: Maryann Xue
>Assignee: Maryann Xue
>Priority: Minor
> Fix For: 4.14.0, 5.0.0
>
> Attachments: PHOENIX-4322.patch
>
>
> Example:
> {code}
> @Test
> public void inDescCompositePK3() throws Exception {
> String table = generateUniqueName();
> String ddl = "CREATE table " + table + " (oid VARCHAR NOT NULL, code 
> VARCHAR NOT NULL constraint pk primary key (oid DESC, code DESC))";
> Object[][] insertedRows = new Object[][]{{"o1", "1"}, {"o2", "2"}, 
> {"o3", "3"}};
> runQueryTest(ddl, upsert("oid", "code"), insertedRows, new 
> Object[][]{{"o2", "2"}, {"o1", "1"}}, new WhereCondition("(oid, code)", "IN", 
> "(('o2', '2'), ('o1', '1'))"),
> table);
> }
> {code}
> Here the last column in primary key is in DESC order and has variable length, 
> and WHERE clause involves an "IN" operator with RowValueConstructor 
> specifying all PK columns. We get no results.
> This ends up being the root cause for not being able to use child/parent join 
> optimization on DESC pk columns as described in PHOENIX-3050.



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

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

2018-02-23 Thread Rajeshbabu Chintaguntla (JIRA) 

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

Rajeshbabu Chintaguntla commented on PHOENIX-3837:
--

Committed the compilation issues. Any progress in this [~aertoria]?

> 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
>
> Attachments: PHOENIX-3837-Merged_With_5.x-2.0-and-Master.patch, 
> PHOENIX-3837.patch
>
>
> {{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
(v7.6.3#76005)

[jira] [Updated] (PHOENIX-3050) Handle DESC columns in child/parent join optimization

2018-02-23 Thread Rajeshbabu Chintaguntla (JIRA) 

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

Rajeshbabu Chintaguntla updated PHOENIX-3050:
-
Fix Version/s: 5.0.0

> Handle DESC columns in child/parent join optimization
> -
>
> Key: PHOENIX-3050
> URL: https://issues.apache.org/jira/browse/PHOENIX-3050
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.8.0
>Reporter: Maryann Xue
>Assignee: Maryann Xue
>Priority: Minor
> Fix For: 4.14.0, 5.0.0
>
> Attachments: PHOENIX-3050.patch
>
>
> We found that child/parent join optimization would not work with DESC pk 
> columns. So as a quick fix for PHOENIX-3029, we simply avoid DESC columns 
> when optimizing, which would have no impact on the overall approach and no 
> impact on ASC columns.
>  
> But eventually we need to make the optimization work with DESC columns too.



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

[jira] [Updated] (PHOENIX-4437) Make QueryPlan.getEstimatedBytesToScan() independent of getExplainPlan() and pull optimize() out of getExplainPlan()

2018-02-23 Thread Rajeshbabu Chintaguntla (JIRA) 

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

Rajeshbabu Chintaguntla updated PHOENIX-4437:
-
Fix Version/s: 5.0.0

> Make QueryPlan.getEstimatedBytesToScan() independent of getExplainPlan() and 
> pull optimize() out of getExplainPlan()
> 
>
> Key: PHOENIX-4437
> URL: https://issues.apache.org/jira/browse/PHOENIX-4437
> Project: Phoenix
>  Issue Type: Improvement
>Affects Versions: 4.11.0
>Reporter: Maryann Xue
>Assignee: Maryann Xue
>Priority: Major
> Fix For: 4.14.0, 5.0.0
>
> Attachments: PHOENIX-4437.patch
>
>




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

[jira] [Commented] (PHOENIX-4548) UpgradeUtil.mapChildViewsToNamespace does not handle multi-tenant views that have the same name.

2018-02-23 Thread Rajeshbabu Chintaguntla (JIRA) 

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

Rajeshbabu Chintaguntla commented on PHOENIX-4548:
--

[~tdsilva] Sorry yeah it's present in 5.x. Thanks.

> UpgradeUtil.mapChildViewsToNamespace does not handle multi-tenant views that 
> have the same name.
> 
>
> Key: PHOENIX-4548
> URL: https://issues.apache.org/jira/browse/PHOENIX-4548
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Thomas D'Silva
>Assignee: Thomas D'Silva
>Priority: Major
> Fix For: 4.14.0, 5.0.0
>
> Attachments: PHOENIX-4548.patch
>
>




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

[jira] [Updated] (PHOENIX-1556) Base hash versus sort merge join decision on cost

2018-02-23 Thread Rajeshbabu Chintaguntla (JIRA) 

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

Rajeshbabu Chintaguntla updated PHOENIX-1556:
-
Fix Version/s: 5.0.0

> Base hash versus sort merge join decision on cost
> -
>
> Key: PHOENIX-1556
> URL: https://issues.apache.org/jira/browse/PHOENIX-1556
> Project: Phoenix
>  Issue Type: Sub-task
>Reporter: James Taylor
>Assignee: Maryann Xue
>Priority: Major
>  Labels: CostBasedOptimization
> Fix For: 4.14.0, 5.0.0
>
> Attachments: PHOENIX-1556.patch
>
>
> At compile time, we know how many guideposts (i.e. how many bytes) will be 
> scanned for the RHS table. We should, by default, base the decision of using 
> the hash-join verus many-to-many join on this information.
> Another criteria (as we've seen in PHOENIX-4508) is whether or not the tables 
> being joined are already ordered by the join key. In that case, it's better 
> to always use the sort merge join.



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

[jira] [Updated] (PHOENIX-1267) Set scan.setSmall(true) when appropriate

2018-02-23 Thread Abhishek Singh Chouhan (JIRA) 

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

Abhishek Singh Chouhan updated PHOENIX-1267:

Attachment: PHOENIX-1267.master.patch

> Set scan.setSmall(true) when appropriate
> 
>
> Key: PHOENIX-1267
> URL: https://issues.apache.org/jira/browse/PHOENIX-1267
> Project: Phoenix
>  Issue Type: Bug
>Reporter: James Taylor
>Assignee: Abhishek Singh Chouhan
>Priority: Major
>  Labels: SFDC, newbie
> Fix For: 4.14.0
>
> Attachments: PHOENIX-1267.master.patch, smallscan.patch, 
> smallscan2.patch, smallscan3.patch
>
>
> There's a nice optimization that has been in HBase for a while now to set a 
> scan as "small". This prevents extra RPC calls, I believe. We should add a 
> hint for queries that forces it to be set/not set, and make our best guess on 
> when it should default to true.



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

[jira] [Commented] (PHOENIX-4622) Phoenix 4.13 order by issue

2018-02-23 Thread JeongMin Ju (JIRA) 

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

JeongMin Ju commented on PHOENIX-4622:
--

I think there is a problem when there is only a date column in the order by 
clause.

If other columns are present together, they are processed normally.

There seems to be something wrong with the reverse scan.

> Phoenix 4.13 order by issue
> ---
>
> Key: PHOENIX-4622
> URL: https://issues.apache.org/jira/browse/PHOENIX-4622
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.13.1
> Environment: phoenix 4.13
> hbase 1.2.5
>Reporter: tom thmas
>Priority: Critical
>
> *1.create table and insert data.*
> create table test2
> (
>  id varchar(200) primary key,
>  cardid varchar(200),
>  ctime date 
> )
> upsert into test2 (id,cardid,ctime) values('a1','123',to_date('2017-12-01 
> 17:42:45'))
> *2.query sql like this:*
> select id,ctime from test2  where cardid='123' order by ctime
> error log:
> {color:#FF}org.apache.phoenix.exception.PhoenixIOException: 
> org.apache.hadoop.hbase.DoNotRetryIOException: 
> TEST2,,1519221167250.813e4ce0510965a7a7898413da2a17ad.: null{color}
>  



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