[jira] [Commented] (PHOENIX-2036) PhoenixConfigurationUtil should provide a pre-normalize table name to PhoenixRuntime
[ https://issues.apache.org/jira/browse/PHOENIX-2036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14583032#comment-14583032 ] maghamravikiran commented on PHOENIX-2036: -- Yes [~giacomotaylor] . I Will make the change and write few tests around these in the phoenix-pig module. > PhoenixConfigurationUtil should provide a pre-normalize table name to > PhoenixRuntime > > > Key: PHOENIX-2036 > URL: https://issues.apache.org/jira/browse/PHOENIX-2036 > Project: Phoenix > Issue Type: Bug >Reporter: Siddhi Mehta >Priority: Minor > Original Estimate: 24h > Remaining Estimate: 24h > > I was trying a basic store using PhoenixHBaseStorage and ran into some issues > with it complaining about TableNotFoundException. > The table(CUSTOM_ENTITY."z02") in question exists. > Looking at the stacktrace I think its likely related to the change in > PHOENIX-1682 where phoenix runtime expects a pre-normalized table name. > We need to update > PhoenixConfigurationUtil.getSelectColumnMetadataList(Configuration) be pass a > pre-normalized table. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-628) Support native JSON data type
[ https://issues.apache.org/jira/browse/PHOENIX-628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14582991#comment-14582991 ] ASF GitHub Bot commented on PHOENIX-628: GitHub user petercdc opened a pull request: https://github.com/apache/phoenix/pull/88 PHOENIX-628 Support native JSON data type This pull request has following changes: 1. JSON Operator : "->" "->>" "#>" "#>>" 2. JSON Boolean Operactor : "?" "?|" "?&" "<@" "@>" For more detail about how to use these operators, Please See http://www.postgresql.org/docs/9.4/static/functions-json.html You can merge this pull request into a Git repository by running: $ git pull https://github.com/petercdc/phoenix json Alternatively you can review and apply these changes as the patch at: https://github.com/apache/phoenix/pull/88.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #88 commit db4432fa76d4229ad4939c995a0a374004a2a1ff Author: LiChiachi Date: 2015-04-24T11:05:34Z This patch can support json operation operator '->>' can be run commit 415b5257d6b3b6e4347f72fedae626e8e0364443 Author: Andy Date: 2015-04-30T08:54:04Z Add json operation (first ver) commit 3294fccf2d9a5c53ac51e81722a202fdae7ce977 Author: LiChiachi Date: 2015-05-19T05:19:23Z Create Json Point Expression commit 960e0e4eb9001ddbdd83a02cffa2ca04ea061cc4 Author: LiChiachi Date: 2015-05-19T07:03:58Z Append ExpressionType and can be run commit 9c4f02475aa9fa41426f474e320ad34de66d205a Author: LiChiachi Date: 2015-05-19T07:25:41Z Use Byte String to get or put Json Structure commit 2c214ba9590b81f83454b417892fb2fa9dc80c10 Author: Andy Date: 2015-05-19T10:30:53Z Merge branch 'jsonOperatorFromChiachi' into json Conflicts: phoenix-assembly/src/build/components-major-client.xml phoenix-assembly/src/build/server.xml phoenix-core/pom.xml phoenix-core/src/main/antlr3/PhoenixSQL.g phoenix-core/src/main/java/org/apache/phoenix/compile/ExpressionCompiler.java phoenix-core/src/main/java/org/apache/phoenix/expression/ExpressionType.java phoenix-core/src/main/java/org/apache/phoenix/expression/visitor/BaseExpressionVisitor.java phoenix-core/src/main/java/org/apache/phoenix/expression/visitor/CloneExpressionVisitor.java phoenix-core/src/main/java/org/apache/phoenix/expression/visitor/ExpressionVisitor.java phoenix-core/src/main/java/org/apache/phoenix/expression/visitor/StatelessTraverseAllExpressionVisitor.java phoenix-core/src/main/java/org/apache/phoenix/expression/visitor/StatelessTraverseNoExpressionVisitor.java phoenix-core/src/main/java/org/apache/phoenix/parse/JsonPathAsElementParseNode.java phoenix-core/src/main/java/org/apache/phoenix/parse/JsonPathAsTextParseNode.java phoenix-core/src/main/java/org/apache/phoenix/parse/JsonPointAsElementParseNode.java phoenix-core/src/main/java/org/apache/phoenix/parse/JsonPointAsTextParseNode.java phoenix-core/src/main/java/org/apache/phoenix/parse/JsonSingleKeySearchParseNode.java phoenix-core/src/main/java/org/apache/phoenix/parse/ParseNodeFactory.java commit 5257535902ebc430239c9a07464845ab163ef0ff Author: Andy Date: 2015-05-19T10:35:22Z Add JSON Operation commit 09fae4aad2bf875225a68ac04ec0feb4fb618337 Author: LiChiachi Date: 2015-05-21T08:48:43Z Merge branch 'jsonOperator' into jsonForGooYoi Conflicts: phoenix-core/src/main/java/org/apache/phoenix/compile/ExpressionCompiler.java phoenix-core/src/main/java/org/apache/phoenix/expression/ExpressionType.java phoenix-core/src/main/java/org/apache/phoenix/expression/visitor/BaseExpressionVisitor.java phoenix-core/src/main/java/org/apache/phoenix/expression/visitor/CloneExpressionVisitor.java phoenix-core/src/main/java/org/apache/phoenix/expression/visitor/ExpressionVisitor.java phoenix-core/src/main/java/org/apache/phoenix/expression/visitor/StatelessTraverseAllExpressionVisitor.java phoenix-core/src/main/java/org/apache/phoenix/expression/visitor/StatelessTraverseNoExpressionVisitor.java commit d16e731d37649bf562e1b1977b42c75f00555d4b Author: LiChiachi Date: 2015-05-21T08:52:52Z debug for '->' operator commit efdf95dd14955c5329fb7f631e647387a8ca3e93 Author: LiChiachi Date: 2015-05-25T02:41:25Z all operation can be executed. commit a24bf459b315c476129fb41734a18ef9e794f84f Author: Andy Date: 2015-05-27T08:35:05Z Add JSON opeation(fix bug) commit 9acfaa3aab8a038b23390505737897acf38c3852 Author: LiChiachi Date: 2015-05-27T11:35:56Z Merge branch 'jsonToBeMerge' into jsonMain commit 4e500eff05844efac8f209482f03bfa54b4ce9d7 Author: LiChiac
[GitHub] phoenix pull request: PHOENIX-628 Support native JSON data type
GitHub user petercdc opened a pull request: https://github.com/apache/phoenix/pull/88 PHOENIX-628 Support native JSON data type This pull request has following changes: 1. JSON Operator : "->" "->>" "#>" "#>>" 2. JSON Boolean Operactor : "?" "?|" "?&" "<@" "@>" For more detail about how to use these operators, Please See http://www.postgresql.org/docs/9.4/static/functions-json.html You can merge this pull request into a Git repository by running: $ git pull https://github.com/petercdc/phoenix json Alternatively you can review and apply these changes as the patch at: https://github.com/apache/phoenix/pull/88.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #88 commit db4432fa76d4229ad4939c995a0a374004a2a1ff Author: LiChiachi Date: 2015-04-24T11:05:34Z This patch can support json operation operator '->>' can be run commit 415b5257d6b3b6e4347f72fedae626e8e0364443 Author: Andy Date: 2015-04-30T08:54:04Z Add json operation (first ver) commit 3294fccf2d9a5c53ac51e81722a202fdae7ce977 Author: LiChiachi Date: 2015-05-19T05:19:23Z Create Json Point Expression commit 960e0e4eb9001ddbdd83a02cffa2ca04ea061cc4 Author: LiChiachi Date: 2015-05-19T07:03:58Z Append ExpressionType and can be run commit 9c4f02475aa9fa41426f474e320ad34de66d205a Author: LiChiachi Date: 2015-05-19T07:25:41Z Use Byte String to get or put Json Structure commit 2c214ba9590b81f83454b417892fb2fa9dc80c10 Author: Andy Date: 2015-05-19T10:30:53Z Merge branch 'jsonOperatorFromChiachi' into json Conflicts: phoenix-assembly/src/build/components-major-client.xml phoenix-assembly/src/build/server.xml phoenix-core/pom.xml phoenix-core/src/main/antlr3/PhoenixSQL.g phoenix-core/src/main/java/org/apache/phoenix/compile/ExpressionCompiler.java phoenix-core/src/main/java/org/apache/phoenix/expression/ExpressionType.java phoenix-core/src/main/java/org/apache/phoenix/expression/visitor/BaseExpressionVisitor.java phoenix-core/src/main/java/org/apache/phoenix/expression/visitor/CloneExpressionVisitor.java phoenix-core/src/main/java/org/apache/phoenix/expression/visitor/ExpressionVisitor.java phoenix-core/src/main/java/org/apache/phoenix/expression/visitor/StatelessTraverseAllExpressionVisitor.java phoenix-core/src/main/java/org/apache/phoenix/expression/visitor/StatelessTraverseNoExpressionVisitor.java phoenix-core/src/main/java/org/apache/phoenix/parse/JsonPathAsElementParseNode.java phoenix-core/src/main/java/org/apache/phoenix/parse/JsonPathAsTextParseNode.java phoenix-core/src/main/java/org/apache/phoenix/parse/JsonPointAsElementParseNode.java phoenix-core/src/main/java/org/apache/phoenix/parse/JsonPointAsTextParseNode.java phoenix-core/src/main/java/org/apache/phoenix/parse/JsonSingleKeySearchParseNode.java phoenix-core/src/main/java/org/apache/phoenix/parse/ParseNodeFactory.java commit 5257535902ebc430239c9a07464845ab163ef0ff Author: Andy Date: 2015-05-19T10:35:22Z Add JSON Operation commit 09fae4aad2bf875225a68ac04ec0feb4fb618337 Author: LiChiachi Date: 2015-05-21T08:48:43Z Merge branch 'jsonOperator' into jsonForGooYoi Conflicts: phoenix-core/src/main/java/org/apache/phoenix/compile/ExpressionCompiler.java phoenix-core/src/main/java/org/apache/phoenix/expression/ExpressionType.java phoenix-core/src/main/java/org/apache/phoenix/expression/visitor/BaseExpressionVisitor.java phoenix-core/src/main/java/org/apache/phoenix/expression/visitor/CloneExpressionVisitor.java phoenix-core/src/main/java/org/apache/phoenix/expression/visitor/ExpressionVisitor.java phoenix-core/src/main/java/org/apache/phoenix/expression/visitor/StatelessTraverseAllExpressionVisitor.java phoenix-core/src/main/java/org/apache/phoenix/expression/visitor/StatelessTraverseNoExpressionVisitor.java commit d16e731d37649bf562e1b1977b42c75f00555d4b Author: LiChiachi Date: 2015-05-21T08:52:52Z debug for '->' operator commit efdf95dd14955c5329fb7f631e647387a8ca3e93 Author: LiChiachi Date: 2015-05-25T02:41:25Z all operation can be executed. commit a24bf459b315c476129fb41734a18ef9e794f84f Author: Andy Date: 2015-05-27T08:35:05Z Add JSON opeation(fix bug) commit 9acfaa3aab8a038b23390505737897acf38c3852 Author: LiChiachi Date: 2015-05-27T11:35:56Z Merge branch 'jsonToBeMerge' into jsonMain commit 4e500eff05844efac8f209482f03bfa54b4ce9d7 Author: LiChiachi Date: 2015-05-29T04:43:16Z Create JSON operation JUNIT test. commit af6a2ec0ab7d3c74275fe7ee28a6f33e82ccd1b1 Author: LiChiachi Date: 2015-05-29T05:56:19Z Update JUNIT test commit 453576bc906374a25418cf408f43b43ba7b2ef10 Author: Andy Date
[jira] [Commented] (PHOENIX-1987) SIGN built-in function should be order preserving
[
https://issues.apache.org/jira/browse/PHOENIX-1987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14582830#comment-14582830
]
James Taylor commented on PHOENIX-1987:
---
bq. Is math function order preserving means it is monotonic?
Yes
> SIGN built-in function should be order preserving
> -
>
> Key: PHOENIX-1987
> URL: https://issues.apache.org/jira/browse/PHOENIX-1987
> Project: Phoenix
> Issue Type: Sub-task
>Reporter: James Taylor
>Assignee: Shuxiong Ye
> Fix For: 5.0.0, 4.5.0, 4.4.1
>
> Attachments:
> 0001-PHOENIX-1987-SIGN-built-in-function-should-be-order_v2.patch,
> 0001-PHOENIX-1987-fixing-getKeyFormationTraversalIndex-in-SIGN-function.patch
>
>
> The SIGN built-in function preserves the order of its input. This needs to be
> explicitly implemented in SignFunction by implementing the following method:
> {code}
> public OrderPreserving preservesOrder() {
> return OrderPreserving.YES;
> }
> {code}
> This will allow certain optimizations reducing the amount of memory and/or
> buffering that is required if SIGN is used in a GROUP BY or ORDER BY clause.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (PHOENIX-1987) SIGN built-in function should be order preserving
[
https://issues.apache.org/jira/browse/PHOENIX-1987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14582826#comment-14582826
]
James Taylor edited comment on PHOENIX-1987 at 6/12/15 2:06 AM:
Not 100% sure, but I think we should throw if NaN happens. For example, we
throw on an attempt to divide by zero. Would be good to confirm what other
databases do, like Postgres or mySQL.
Don't return false, though, as that should only be returned if you don't have
enough information to compute a value. In this case, you have all the
information you need, it's just that you can't compute a value.
was (Author: jamestaylor):
Not 100% sure, but I think we should throw if NaN happens. For example, we
throw on an attempt to divide by zero. Would be good to confirm what other
databases do, like Postgres or mySQL.
> SIGN built-in function should be order preserving
> -
>
> Key: PHOENIX-1987
> URL: https://issues.apache.org/jira/browse/PHOENIX-1987
> Project: Phoenix
> Issue Type: Sub-task
>Reporter: James Taylor
>Assignee: Shuxiong Ye
> Fix For: 5.0.0, 4.5.0, 4.4.1
>
> Attachments:
> 0001-PHOENIX-1987-SIGN-built-in-function-should-be-order_v2.patch,
> 0001-PHOENIX-1987-fixing-getKeyFormationTraversalIndex-in-SIGN-function.patch
>
>
> The SIGN built-in function preserves the order of its input. This needs to be
> explicitly implemented in SignFunction by implementing the following method:
> {code}
> public OrderPreserving preservesOrder() {
> return OrderPreserving.YES;
> }
> {code}
> This will allow certain optimizations reducing the amount of memory and/or
> buffering that is required if SIGN is used in a GROUP BY or ORDER BY clause.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PHOENIX-1987) SIGN built-in function should be order preserving
[
https://issues.apache.org/jira/browse/PHOENIX-1987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14582826#comment-14582826
]
James Taylor commented on PHOENIX-1987:
---
Not 100% sure, but I think we should throw if NaN happens. For example, we
throw on an attempt to divide by zero. Would be good to confirm what other
databases do, like Postgres or mySQL.
> SIGN built-in function should be order preserving
> -
>
> Key: PHOENIX-1987
> URL: https://issues.apache.org/jira/browse/PHOENIX-1987
> Project: Phoenix
> Issue Type: Sub-task
>Reporter: James Taylor
>Assignee: Shuxiong Ye
> Fix For: 5.0.0, 4.5.0, 4.4.1
>
> Attachments:
> 0001-PHOENIX-1987-SIGN-built-in-function-should-be-order_v2.patch,
> 0001-PHOENIX-1987-fixing-getKeyFormationTraversalIndex-in-SIGN-function.patch
>
>
> The SIGN built-in function preserves the order of its input. This needs to be
> explicitly implemented in SignFunction by implementing the following method:
> {code}
> public OrderPreserving preservesOrder() {
> return OrderPreserving.YES;
> }
> {code}
> This will allow certain optimizations reducing the amount of memory and/or
> buffering that is required if SIGN is used in a GROUP BY or ORDER BY clause.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PHOENIX-1987) SIGN built-in function should be order preserving
[
https://issues.apache.org/jira/browse/PHOENIX-1987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14582821#comment-14582821
]
James Taylor commented on PHOENIX-1987:
---
One more request: can you add negative tests in QueryCompilerTest that when you
match the leading pk column in an equality expression using these math
functions, that there's no start/stop key formed for the scan:
{code}
SELECT * FROM T WHERE SQRT(pk) == 2.0;
...
Scan scan = compileQuery(query, binds);
assertNotNull(scan.getFilter());
assertTrue(scan.getStartRow().length == 0);
assertTrue(scan.getStopRow().length == 0);
{code}
> SIGN built-in function should be order preserving
> -
>
> Key: PHOENIX-1987
> URL: https://issues.apache.org/jira/browse/PHOENIX-1987
> Project: Phoenix
> Issue Type: Sub-task
>Reporter: James Taylor
>Assignee: Shuxiong Ye
> Fix For: 5.0.0, 4.5.0, 4.4.1
>
> Attachments:
> 0001-PHOENIX-1987-SIGN-built-in-function-should-be-order_v2.patch,
> 0001-PHOENIX-1987-fixing-getKeyFormationTraversalIndex-in-SIGN-function.patch
>
>
> The SIGN built-in function preserves the order of its input. This needs to be
> explicitly implemented in SignFunction by implementing the following method:
> {code}
> public OrderPreserving preservesOrder() {
> return OrderPreserving.YES;
> }
> {code}
> This will allow certain optimizations reducing the amount of memory and/or
> buffering that is required if SIGN is used in a GROUP BY or ORDER BY clause.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PHOENIX-1987) SIGN built-in function should be order preserving
[
https://issues.apache.org/jira/browse/PHOENIX-1987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14582818#comment-14582818
]
Shuxiong Ye commented on PHOENIX-1987:
--
Is math function order preserving means it is monotonic?
In some case, for illegal argument, the math function will return NaN, which is
the same as Java.Math.*
when NaN appears, should we make the evaluation fail and return false?
> SIGN built-in function should be order preserving
> -
>
> Key: PHOENIX-1987
> URL: https://issues.apache.org/jira/browse/PHOENIX-1987
> Project: Phoenix
> Issue Type: Sub-task
>Reporter: James Taylor
>Assignee: Shuxiong Ye
> Fix For: 5.0.0, 4.5.0, 4.4.1
>
> Attachments:
> 0001-PHOENIX-1987-SIGN-built-in-function-should-be-order_v2.patch,
> 0001-PHOENIX-1987-fixing-getKeyFormationTraversalIndex-in-SIGN-function.patch
>
>
> The SIGN built-in function preserves the order of its input. This needs to be
> explicitly implemented in SignFunction by implementing the following method:
> {code}
> public OrderPreserving preservesOrder() {
> return OrderPreserving.YES;
> }
> {code}
> This will allow certain optimizations reducing the amount of memory and/or
> buffering that is required if SIGN is used in a GROUP BY or ORDER BY clause.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PHOENIX-1987) SIGN built-in function should be order preserving
[
https://issues.apache.org/jira/browse/PHOENIX-1987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14582811#comment-14582811
]
James Taylor commented on PHOENIX-1987:
---
I see - good find. Looks like if you override perservesOrder(), then you also
must override getKeyFormationTraversalIndex. We should either change the
default implementation for getKeyFormationTraversalIndex() in ScalarFunction to
this:
{code}
public int getKeyFormationTraversalIndex() {
return preservesOrder() == OrderPreserving.NO ? NO_TRAVERSAL : 0;
}
{code}
Having the default be 0 in this case makes sense, as it's pretty much always
been the case that the first argument is the one that needs to be considered.
Or at a minimum, add a note to the java doc for
FunctionExpression.preservesOrder() and for
ScalarFunction.getKeyFormationTraversalIndex().
Also, any corner case that make these math functions not order preserving (i.e.
using negative values for first or second argument, etc.)?
> SIGN built-in function should be order preserving
> -
>
> Key: PHOENIX-1987
> URL: https://issues.apache.org/jira/browse/PHOENIX-1987
> Project: Phoenix
> Issue Type: Sub-task
>Reporter: James Taylor
>Assignee: Shuxiong Ye
> Fix For: 5.0.0, 4.5.0, 4.4.1
>
> Attachments:
> 0001-PHOENIX-1987-SIGN-built-in-function-should-be-order_v2.patch,
> 0001-PHOENIX-1987-fixing-getKeyFormationTraversalIndex-in-SIGN-function.patch
>
>
> The SIGN built-in function preserves the order of its input. This needs to be
> explicitly implemented in SignFunction by implementing the following method:
> {code}
> public OrderPreserving preservesOrder() {
> return OrderPreserving.YES;
> }
> {code}
> This will allow certain optimizations reducing the amount of memory and/or
> buffering that is required if SIGN is used in a GROUP BY or ORDER BY clause.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PHOENIX-1687) Implement missing math built-in POWER function
[ https://issues.apache.org/jira/browse/PHOENIX-1687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14582809#comment-14582809 ] Shuxiong Ye commented on PHOENIX-1687: -- 1. I will try to modify the patch to remove these two functions. 2. see [1], not override this function will cause exception, and I don't know to eliminate it. [1] https://issues.apache.org/jira/browse/PHOENIX-1987?focusedCommentId=14582803&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14582803 > Implement missing math built-in POWER function > -- > > Key: PHOENIX-1687 > URL: https://issues.apache.org/jira/browse/PHOENIX-1687 > Project: Phoenix > Issue Type: Sub-task >Reporter: Aakarsh Agarwal >Assignee: Shuxiong Ye > Labels: gsoc2015, java > Fix For: 5.0.0, 4.5.0 > > Attachments: add-function-PHOENIX-1611-1687-2015-2019-2020.patch > > > Take a look at the typical math functions that are implemented in relational > database systems > (http://www.postgresql.org/docs/current/static/functions-math.html) and > implement the same for Phoenix in Java following this guide: > http://phoenix-hbase.blogspot.com/2013/04/how-to-add-your-own-built-in-function.html > For this specific task, it is meant to implement missing funstion POWER for > Phoenix in Java. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-1687) Implement missing math built-in POWER function
[
https://issues.apache.org/jira/browse/PHOENIX-1687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14582804#comment-14582804
]
James Taylor commented on PHOENIX-1687:
---
Thanks, [~shuxi0ng]. Looking good. Here's some feedback:
- Can we get rid of these methods, as the default value can be declared in the
annotation (and we wouldn't want to duplicate the default value in a method)?
Also, if you use e notation in the specification of the default, you should end
up with a double value for that argument (not sure if that's an issue in your
case or not). When you declare a default value, Phoenix should pass bind that
argument to the default value when it's not provided.
{code}
+@Override
+protected boolean isSecondArgHasDefaultValue() {
+return true;
+}
+
+@Override
+protected double getSecondArgDefaultValue() {
+return 10.0;
+}
+
{code}
- I don't believe you'll want to override this anywhere. Or are you finding
that it's necessary for some reason?
{code}
+@Override
+public int getKeyFormationTraversalIndex() {
+return 0;
+}
{code}
> Implement missing math built-in POWER function
> --
>
> Key: PHOENIX-1687
> URL: https://issues.apache.org/jira/browse/PHOENIX-1687
> Project: Phoenix
> Issue Type: Sub-task
>Reporter: Aakarsh Agarwal
>Assignee: Shuxiong Ye
> Labels: gsoc2015, java
> Fix For: 5.0.0, 4.5.0
>
> Attachments: add-function-PHOENIX-1611-1687-2015-2019-2020.patch
>
>
> Take a look at the typical math functions that are implemented in relational
> database systems
> (http://www.postgresql.org/docs/current/static/functions-math.html) and
> implement the same for Phoenix in Java following this guide:
> http://phoenix-hbase.blogspot.com/2013/04/how-to-add-your-own-built-in-function.html
> For this specific task, it is meant to implement missing funstion POWER for
> Phoenix in Java.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PHOENIX-1987) SIGN built-in function should be order preserving
[
https://issues.apache.org/jira/browse/PHOENIX-1987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14582803#comment-14582803
]
Shuxiong Ye commented on PHOENIX-1987:
--
If not override getKeyFormationTraversalIndex in SignFunction, the below
statement will get java.lang.IndexOutOfBoundsException, which I go deep into
it, and find it caused by SignFunction's super class ScalarFunction's function
getKeyFormationTraversalIndex
{code:java}
QueryPlan plan =
conn.createStatement().unwrap(PhoenixStatement.class).compileQuery(query);
{code}
ScalarFunction's function getKeyFormationTraversalIndex looks like
{code:java}
public int getKeyFormationTraversalIndex() {
return NO_TRAVERSAL; // --> it is -1
}
{code}
I happen to refer to RoundDateExpression previously, and it also has
getKeyFormationTraversalIndex which returns 0, too.
Is there any Expression I can refer to?
Thanks
> SIGN built-in function should be order preserving
> -
>
> Key: PHOENIX-1987
> URL: https://issues.apache.org/jira/browse/PHOENIX-1987
> Project: Phoenix
> Issue Type: Sub-task
>Reporter: James Taylor
>Assignee: Shuxiong Ye
> Fix For: 5.0.0, 4.5.0, 4.4.1
>
> Attachments:
> 0001-PHOENIX-1987-SIGN-built-in-function-should-be-order_v2.patch,
> 0001-PHOENIX-1987-fixing-getKeyFormationTraversalIndex-in-SIGN-function.patch
>
>
> The SIGN built-in function preserves the order of its input. This needs to be
> explicitly implemented in SignFunction by implementing the following method:
> {code}
> public OrderPreserving preservesOrder() {
> return OrderPreserving.YES;
> }
> {code}
> This will allow certain optimizations reducing the amount of memory and/or
> buffering that is required if SIGN is used in a GROUP BY or ORDER BY clause.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (PHOENIX-1987) SIGN built-in function should be order preserving
[
https://issues.apache.org/jira/browse/PHOENIX-1987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14582787#comment-14582787
]
James Taylor edited comment on PHOENIX-1987 at 6/12/15 1:22 AM:
Don't override getKeyFormationTraversalIndex. That's only used for cases in
which a function preserves the original identify of the argument. An example is
CoerceExpression which changes the type, but preserves the identify. Another is
the INVERT function which is the same as the original with just the bits
inverted. That won't be the case for these math functions.
I believe the following query should use a reverse scan:
{code}
SELECT * FROM T ORDER BY TRUNC(k1, 'DAY') DESC, CEIL(k2, 'HOUR')
{code}
All the CEIL, TRUNC, FLOOR, ROUND functions output their argument in ASC order,
even if they come in DESC. So having an ORDER BY clause like the above, it
should be order preserving. Is that what you're finding?
FYI, you can check if the order is forward versus reverse by comparing the
plan.getOrderBy() with OrderBy.FWD_ROW_KEY_ORDER_BY or
OrderBy.REV_ROW_KEY_ORDER_BY as you can see in some of the tests in
QueryCompilerTest.
was (Author: jamestaylor):
Don't override getKeyFormationTraversalIndex. That's only used for cases in
which a function preserves the original identify of the argument. An example is
CoerceExpression which changes the type, but preserves the identify. Another is
the INVERT(x) which is the same as the original with just the bits inverted.
That won't be the case for these math functions.
I believe the following query should use a reverse scan:
{code}
SELECT * FROM T ORDER BY TRUNC(k1, 'DAY') DESC, CEIL(k2, 'HOUR')
{code}
All the CEIL, TRUNC, FLOOR, ROUND functions output their argument in ASC order,
even if they come in DESC. So having an ORDER BY clause like the above, it
should be order preserving. Is that what you're finding?
FYI, you can check if the order is forward versus reverse by comparing the
plan.getOrderBy() with OrderBy.FWD_ROW_KEY_ORDER_BY or
OrderBy.REV_ROW_KEY_ORDER_BY as you can see in some of the tests in
QueryCompilerTest.
> SIGN built-in function should be order preserving
> -
>
> Key: PHOENIX-1987
> URL: https://issues.apache.org/jira/browse/PHOENIX-1987
> Project: Phoenix
> Issue Type: Sub-task
>Reporter: James Taylor
>Assignee: Shuxiong Ye
> Fix For: 5.0.0, 4.5.0, 4.4.1
>
> Attachments:
> 0001-PHOENIX-1987-SIGN-built-in-function-should-be-order_v2.patch,
> 0001-PHOENIX-1987-fixing-getKeyFormationTraversalIndex-in-SIGN-function.patch
>
>
> The SIGN built-in function preserves the order of its input. This needs to be
> explicitly implemented in SignFunction by implementing the following method:
> {code}
> public OrderPreserving preservesOrder() {
> return OrderPreserving.YES;
> }
> {code}
> This will allow certain optimizations reducing the amount of memory and/or
> buffering that is required if SIGN is used in a GROUP BY or ORDER BY clause.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PHOENIX-1987) SIGN built-in function should be order preserving
[
https://issues.apache.org/jira/browse/PHOENIX-1987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14582787#comment-14582787
]
James Taylor commented on PHOENIX-1987:
---
Don't override getKeyFormationTraversalIndex. That's only used for cases in
which a function preserves the original identify of the argument. An example is
CoerceExpression which changes the type, but preserves the identify. Another is
the INVERT(x) which is the same as the original with just the bits inverted.
That won't be the case for these math functions.
I believe the following query should use a reverse scan:
{code}
SELECT * FROM T ORDER BY TRUNC(k1, 'DAY') DESC, CEIL(k2, 'HOUR')
{code}
All the CEIL, TRUNC, FLOOR, ROUND functions output their argument in ASC order,
even if they come in DESC. So having an ORDER BY clause like the above, it
should be order preserving. Is that what you're finding?
FYI, you can check if the order is forward versus reverse by comparing the
plan.getOrderBy() with OrderBy.FWD_ROW_KEY_ORDER_BY or
OrderBy.REV_ROW_KEY_ORDER_BY as you can see in some of the tests in
QueryCompilerTest.
> SIGN built-in function should be order preserving
> -
>
> Key: PHOENIX-1987
> URL: https://issues.apache.org/jira/browse/PHOENIX-1987
> Project: Phoenix
> Issue Type: Sub-task
>Reporter: James Taylor
>Assignee: Shuxiong Ye
> Fix For: 5.0.0, 4.5.0, 4.4.1
>
> Attachments:
> 0001-PHOENIX-1987-SIGN-built-in-function-should-be-order_v2.patch,
> 0001-PHOENIX-1987-fixing-getKeyFormationTraversalIndex-in-SIGN-function.patch
>
>
> The SIGN built-in function preserves the order of its input. This needs to be
> explicitly implemented in SignFunction by implementing the following method:
> {code}
> public OrderPreserving preservesOrder() {
> return OrderPreserving.YES;
> }
> {code}
> This will allow certain optimizations reducing the amount of memory and/or
> buffering that is required if SIGN is used in a GROUP BY or ORDER BY clause.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PHOENIX-2015) Implement Build-in math function CBRT
[ https://issues.apache.org/jira/browse/PHOENIX-2015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14582776#comment-14582776 ] Shuxiong Ye commented on PHOENIX-2015: -- I update these patch in [1]. it contains this build-in function. : ) [1] https://issues.apache.org/jira/browse/PHOENIX-1687?focusedCommentId=14580892&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14580892 > Implement Build-in math function CBRT > - > > Key: PHOENIX-2015 > URL: https://issues.apache.org/jira/browse/PHOENIX-2015 > Project: Phoenix > Issue Type: Sub-task >Reporter: Shuxiong Ye >Assignee: Shuxiong Ye > Fix For: 5.0.0, 4.5.0, 4.4.1 > > Attachments: > 0001-PHOENIX-2015-Implement-Build-in-math-function-CBRT_v2.patch > > > Implement math build-in function cube root -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-2020) Implement build-in math function EXP
[ https://issues.apache.org/jira/browse/PHOENIX-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14582774#comment-14582774 ] Shuxiong Ye commented on PHOENIX-2020: -- I update these patch in [1]. it contains this build-in function. : ) [1] https://issues.apache.org/jira/browse/PHOENIX-1687?focusedCommentId=14580892&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14580892 > Implement build-in math function EXP > > > Key: PHOENIX-2020 > URL: https://issues.apache.org/jira/browse/PHOENIX-2020 > Project: Phoenix > Issue Type: Sub-task >Reporter: Shuxiong Ye >Assignee: Shuxiong Ye > Fix For: 5.0.0, 4.5.0, 4.4.1 > > Attachments: > 0001-PHOENIX-2020-Implement-build-in-math-function-EXP.patch > > > EXP is exponential function, and will be a special case of POWER function. > Examples show as below: > exp(dp) exponential exp(1.0)2.71828182845905 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-2019) Implement Build-in math function ln and log
[ https://issues.apache.org/jira/browse/PHOENIX-2019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14582767#comment-14582767 ] Shuxiong Ye commented on PHOENIX-2019: -- I update these patch in [1]. it contains some build-in function. : ) [1] https://issues.apache.org/jira/browse/PHOENIX-1687?focusedCommentId=14580892&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14580892 > Implement Build-in math function ln and log > --- > > Key: PHOENIX-2019 > URL: https://issues.apache.org/jira/browse/PHOENIX-2019 > Project: Phoenix > Issue Type: Sub-task >Reporter: Shuxiong Ye >Assignee: Shuxiong Ye > Fix For: 5.0.0, 4.5.0, 4.4.1 > > Attachments: > 0001-PHOENIX-2019-Implement-Build-in-math-function-ln-and.patch > > > Implement math build-in function, ln and log. Example show as below: > ln(dp)natural logarithm ln(2.0) 0.693147180559945 > log(dp) base 10 logarithm log(100.0) 2 > log(b, x) numeric logarithm to base b log(2.0, 64.0) 6.00 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-2019) Implement Build-in math function ln and log
[ https://issues.apache.org/jira/browse/PHOENIX-2019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14582760#comment-14582760 ] James Taylor commented on PHOENIX-2019: --- I'd recommend using your JavaMathOneArgumentFunction base class for all these. Just remove the implementation of getOrderPreserving there and include that instead directly in the built-in function implementation class where it's the case. Also, there's really no advantage to preserving the sort order in these functions (i.e. same feedback I gave you for SQRT). Just don't call coerceBytes in the evaluate method and don't specialize the getSortOrder method. > Implement Build-in math function ln and log > --- > > Key: PHOENIX-2019 > URL: https://issues.apache.org/jira/browse/PHOENIX-2019 > Project: Phoenix > Issue Type: Sub-task >Reporter: Shuxiong Ye >Assignee: Shuxiong Ye > Fix For: 5.0.0, 4.5.0, 4.4.1 > > Attachments: > 0001-PHOENIX-2019-Implement-Build-in-math-function-ln-and.patch > > > Implement math build-in function, ln and log. Example show as below: > ln(dp)natural logarithm ln(2.0) 0.693147180559945 > log(dp) base 10 logarithm log(100.0) 2 > log(b, x) numeric logarithm to base b log(2.0, 64.0) 6.00 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-1981) PhoenixHBase Load and Store Funcs should handle all Pig data types
[
https://issues.apache.org/jira/browse/PHOENIX-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14582749#comment-14582749
]
ASF GitHub Bot commented on PHOENIX-1981:
-
Github user JamesRTaylor commented on a diff in the pull request:
https://github.com/apache/phoenix/pull/85#discussion_r32283255
--- Diff:
phoenix-pig/src/test/java/org/apache/phoenix/pig/util/TypeUtilTest.java ---
@@ -0,0 +1,70 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.phoenix.pig.util;
+
+import static org.junit.Assert.assertEquals;
+import static org.mockito.Mockito.mock;
+import static org.mockito.Mockito.when;
+
+import java.math.BigDecimal;
+import java.math.BigInteger;
+import java.util.List;
+
+import org.apache.phoenix.pig.writable.PhoenixPigDBWritable;
+import org.apache.pig.ResourceSchema.ResourceFieldSchema;
+import org.apache.pig.data.DataType;
+import org.apache.pig.data.Tuple;
+import org.junit.Test;
+
+import com.google.common.collect.Lists;
+
+public class TypeUtilTest {
+
+@Test
+public void testTransformToTuple() throws Exception {
+PhoenixPigDBWritable record = mock(PhoenixPigDBWritable.class);
+List values = Lists.newArrayList();
+values.add("213123");
+values.add(1231123);
+values.add(31231231232131L);
+values.add("bytearray".getBytes());
+when(record.getValues()).thenReturn(values);
+
+ResourceFieldSchema field = new
ResourceFieldSchema().setType(DataType.CHARARRAY);
--- End diff --
Thanks, @elilevine. I +1'ed it on the JIRA, so please commit. We're
targeting a 4.4.1 next week.
> PhoenixHBase Load and Store Funcs should handle all Pig data types
> --
>
> Key: PHOENIX-1981
> URL: https://issues.apache.org/jira/browse/PHOENIX-1981
> Project: Phoenix
> Issue Type: Improvement
>Reporter: Prashant Kommireddi
>Assignee: Prashant Kommireddi
>
> The load and store func (Pig integration) currently do not handle all Pig
> types. Here is a complete list
> http://pig.apache.org/docs/r0.13.0/basic.html#data-types
> In addition to handling all simple types (BigInteger and BigDecimal are
> missing in the LoadFunc currently), we should also look into handling complex
> Pig types.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] phoenix pull request: PHOENIX-1981 : PhoenixHBase Load and Store F...
Github user JamesRTaylor commented on a diff in the pull request:
https://github.com/apache/phoenix/pull/85#discussion_r32283255
--- Diff:
phoenix-pig/src/test/java/org/apache/phoenix/pig/util/TypeUtilTest.java ---
@@ -0,0 +1,70 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.phoenix.pig.util;
+
+import static org.junit.Assert.assertEquals;
+import static org.mockito.Mockito.mock;
+import static org.mockito.Mockito.when;
+
+import java.math.BigDecimal;
+import java.math.BigInteger;
+import java.util.List;
+
+import org.apache.phoenix.pig.writable.PhoenixPigDBWritable;
+import org.apache.pig.ResourceSchema.ResourceFieldSchema;
+import org.apache.pig.data.DataType;
+import org.apache.pig.data.Tuple;
+import org.junit.Test;
+
+import com.google.common.collect.Lists;
+
+public class TypeUtilTest {
+
+@Test
+public void testTransformToTuple() throws Exception {
+PhoenixPigDBWritable record = mock(PhoenixPigDBWritable.class);
+List values = Lists.newArrayList();
+values.add("213123");
+values.add(1231123);
+values.add(31231231232131L);
+values.add("bytearray".getBytes());
+when(record.getValues()).thenReturn(values);
+
+ResourceFieldSchema field = new
ResourceFieldSchema().setType(DataType.CHARARRAY);
--- End diff --
Thanks, @elilevine. I +1'ed it on the JIRA, so please commit. We're
targeting a 4.4.1 next week.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[jira] [Commented] (PHOENIX-2036) PhoenixConfigurationUtil should provide a pre-normalize table name to PhoenixRuntime
[ https://issues.apache.org/jira/browse/PHOENIX-2036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14582740#comment-14582740 ] James Taylor commented on PHOENIX-2036: --- Sound ok, [~maghamravikiran]? > PhoenixConfigurationUtil should provide a pre-normalize table name to > PhoenixRuntime > > > Key: PHOENIX-2036 > URL: https://issues.apache.org/jira/browse/PHOENIX-2036 > Project: Phoenix > Issue Type: Bug >Reporter: Siddhi Mehta >Priority: Minor > Original Estimate: 24h > Remaining Estimate: 24h > > I was trying a basic store using PhoenixHBaseStorage and ran into some issues > with it complaining about TableNotFoundException. > The table(CUSTOM_ENTITY."z02") in question exists. > Looking at the stacktrace I think its likely related to the change in > PHOENIX-1682 where phoenix runtime expects a pre-normalized table name. > We need to update > PhoenixConfigurationUtil.getSelectColumnMetadataList(Configuration) be pass a > pre-normalized table. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-2033) PQS log environment details on launch
[
https://issues.apache.org/jira/browse/PHOENIX-2033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14582686#comment-14582686
]
Enis Soztutar commented on PHOENIX-2033:
bq. Still good by you Enis Soztutar?
Sure. Seems trivial.
> PQS log environment details on launch
> -
>
> Key: PHOENIX-2033
> URL: https://issues.apache.org/jira/browse/PHOENIX-2033
> Project: Phoenix
> Issue Type: Improvement
>Reporter: Nick Dimiduk
>Assignee: Nick Dimiduk
> Fix For: 5.0.0, 4.5.0, 4.4.1
>
> Attachments: PHOENIX-2033.00.patch, PHOENIX-2033.00.patch,
> PHOENIX-2033.01.patch
>
>
> Follow HBase's lead and include environment details in log at process launch.
> There's already a handy utility for this in {{ServerCommandLine}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (PHOENIX-1816) Add markdown page on Phoenix website describing how to use Spark integration
[ https://issues.apache.org/jira/browse/PHOENIX-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Taylor resolved PHOENIX-1816. --- Resolution: Fixed > Add markdown page on Phoenix website describing how to use Spark integration > > > Key: PHOENIX-1816 > URL: https://issues.apache.org/jira/browse/PHOENIX-1816 > Project: Phoenix > Issue Type: Sub-task >Reporter: James Taylor >Assignee: Josh Mahonin > Fix For: 5.0.0, 4.4.0 > > Attachments: README.md > > > Now that we have some nifty integration with Spark, we should add a markdown > page to our site (http://phoenix.apache.org/), with a link in the Using menu > that describes how to use it. > See http://phoenix.apache.org/building_website.html for how to modify the the > website (in lives in svn). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-1816) Add markdown page on Phoenix website describing how to use Spark integration
[ https://issues.apache.org/jira/browse/PHOENIX-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14582676#comment-14582676 ] James Taylor commented on PHOENIX-1816: --- Thanks for the updates, [~jmahonin]. I pushed this to our website (with a couple of minor tweaks). In general, our website is our canonical documentation as many users just download and use our binary distribution so would never see the README.md. FYI, [~maghamravikiran]. > Add markdown page on Phoenix website describing how to use Spark integration > > > Key: PHOENIX-1816 > URL: https://issues.apache.org/jira/browse/PHOENIX-1816 > Project: Phoenix > Issue Type: Sub-task >Reporter: James Taylor >Assignee: Josh Mahonin > Fix For: 5.0.0, 4.4.0 > > Attachments: README.md > > > Now that we have some nifty integration with Spark, we should add a markdown > page to our site (http://phoenix.apache.org/), with a link in the Using menu > that describes how to use it. > See http://phoenix.apache.org/building_website.html for how to modify the the > website (in lives in svn). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-1968) Phoenix-Spark: Should support saving arrays
[ https://issues.apache.org/jira/browse/PHOENIX-1968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14582634#comment-14582634 ] James Taylor commented on PHOENIX-1968: --- Thanks for pushing the patch, [~maghamravikiran]. Don't forget to attribute the patch to [~jmahonin] by putting his name in parenthesis for the commit message like this: PHOENIX 1968: Should support saving arrays (Josh Mahonin) > Phoenix-Spark: Should support saving arrays > --- > > Key: PHOENIX-1968 > URL: https://issues.apache.org/jira/browse/PHOENIX-1968 > Project: Phoenix > Issue Type: Bug >Reporter: Josh Mahonin >Assignee: Josh Mahonin > Attachments: PHOENIX-1968.patch > > > At present, we only use 'setObject' on the PreparedStatement when writing > back to Phoenix. This patch allows calling 'setArray' with the appropriate > sql base type when an array is passed in as a column value. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-2032) psql.py is broken after PHOENIX-2013
[
https://issues.apache.org/jira/browse/PHOENIX-2032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14582628#comment-14582628
]
James Taylor commented on PHOENIX-2032:
---
+1 to option #2 and -1 for option #1
> psql.py is broken after PHOENIX-2013
>
>
> Key: PHOENIX-2032
> URL: https://issues.apache.org/jira/browse/PHOENIX-2032
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 5.0.0, 4.5.0, 4.4.1
>Reporter: Sergio Peleato
>Assignee: Nick Dimiduk
>Priority: Blocker
> Fix For: 5.0.0, 4.5.0, 4.4.1
>
> Attachments: 2032.patch, PHOENIX-2032.00.patch
>
>
> psql is no longer able to load the phoenix driver after PHOENIX-2013.
> {noformat}
> $ ./bin/psql.py localhost examples/WEB_STAT.sql
>
>
> java.sql.SQLException: No suitable driver found for jdbc:phoenix:localhost
> at java.sql.DriverManager.getConnection(DriverManager.java:596)
> at java.sql.DriverManager.getConnection(DriverManager.java:187)
> at
> org.apache.phoenix.util.PhoenixRuntime.main(PhoenixRuntime.java:183)
> {noformat}
> Hat-tip to [~chrajeshbab...@gmail.com] for tracking down the breaking change.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PHOENIX-2034) Update pre-commit branches
[
https://issues.apache.org/jira/browse/PHOENIX-2034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14582573#comment-14582573
]
Samarth Jain commented on PHOENIX-2034:
---
+1 to dropping 3.0, 3.2, 4.0.1, 4.2, 4.3
> Update pre-commit branches
> --
>
> Key: PHOENIX-2034
> URL: https://issues.apache.org/jira/browse/PHOENIX-2034
> Project: Phoenix
> Issue Type: Task
>Reporter: Nick Dimiduk
>Assignee: Nick Dimiduk
> Attachments: 2034.patch
>
>
> Seems our list of precommit branches no longer matches the valid branch names.
> {noformat}
> BRANCH_NAMES="3.0 3.2 4.0.1 4.2 4.3 4.x-HBase-0.98 master"
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (PHOENIX-1839) Enable hash-join with RIGHT OUTER joins
[ https://issues.apache.org/jira/browse/PHOENIX-1839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maryann Xue resolved PHOENIX-1839. -- Resolution: Fixed > Enable hash-join with RIGHT OUTER joins > --- > > Key: PHOENIX-1839 > URL: https://issues.apache.org/jira/browse/PHOENIX-1839 > Project: Phoenix > Issue Type: Sub-task >Reporter: Maryann Xue >Assignee: Maryann Xue >Priority: Minor > Original Estimate: 48h > Remaining Estimate: 48h > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-1968) Phoenix-Spark: Should support saving arrays
[ https://issues.apache.org/jira/browse/PHOENIX-1968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14582451#comment-14582451 ] maghamravikiran commented on PHOENIX-1968: -- Pushed the changes to all branches of 4.4.X and 4.X and master. Thanks [~jmahonin] for the patch. > Phoenix-Spark: Should support saving arrays > --- > > Key: PHOENIX-1968 > URL: https://issues.apache.org/jira/browse/PHOENIX-1968 > Project: Phoenix > Issue Type: Bug >Reporter: Josh Mahonin >Assignee: Josh Mahonin > Attachments: PHOENIX-1968.patch > > > At present, we only use 'setObject' on the PreparedStatement when writing > back to Phoenix. This patch allows calling 'setArray' with the appropriate > sql base type when an array is passed in as a column value. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-2032) psql.py is broken after PHOENIX-2013
[
https://issues.apache.org/jira/browse/PHOENIX-2032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14582392#comment-14582392
]
Gabriel Reid commented on PHOENIX-2032:
---
Aha, I just read all the stuff you put in MASSEMBLY-773, I missed the before. I
see that ticket is resolved now, so I guess there's an option to use the fixed
version of the plugin (although I'm assuming it'll be a while before it's
released).
Of the three options you outlined before, I don't think that option #1 (ship
the broken jar, but add a {{Class.forName}} call in main methods) is viable --
the current jar won't work via SPI in a client that relies on SPI working
without first calling {{Class.forName}} (and I assume that there are clients
that do that).
Option #2 (include the queryserver, or at least queryserver-client) in the fat
phoenix client actually doesn't sound too bad. The fact that the thin client is
included in the fat client uberjar doesn't sound all that crazy. Any idea how
much extra bloat that would add to the fat client jar? Other than that, any
major reason not to do this?
> psql.py is broken after PHOENIX-2013
>
>
> Key: PHOENIX-2032
> URL: https://issues.apache.org/jira/browse/PHOENIX-2032
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 5.0.0, 4.5.0, 4.4.1
>Reporter: Sergio Peleato
>Assignee: Nick Dimiduk
>Priority: Blocker
> Fix For: 5.0.0, 4.5.0, 4.4.1
>
> Attachments: 2032.patch, PHOENIX-2032.00.patch
>
>
> psql is no longer able to load the phoenix driver after PHOENIX-2013.
> {noformat}
> $ ./bin/psql.py localhost examples/WEB_STAT.sql
>
>
> java.sql.SQLException: No suitable driver found for jdbc:phoenix:localhost
> at java.sql.DriverManager.getConnection(DriverManager.java:596)
> at java.sql.DriverManager.getConnection(DriverManager.java:187)
> at
> org.apache.phoenix.util.PhoenixRuntime.main(PhoenixRuntime.java:183)
> {noformat}
> Hat-tip to [~chrajeshbab...@gmail.com] for tracking down the breaking change.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (PHOENIX-2034) Update pre-commit branches
[
https://issues.apache.org/jira/browse/PHOENIX-2034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Dimiduk updated PHOENIX-2034:
--
Attachment: 2034.patch
Simple patch.
What do you think [~jamestaylor], [~gabriel.reid], [~samarthjain]? Are we doing
more releases from the older branches? Want any of them trimmed from the list?
> Update pre-commit branches
> --
>
> Key: PHOENIX-2034
> URL: https://issues.apache.org/jira/browse/PHOENIX-2034
> Project: Phoenix
> Issue Type: Task
>Reporter: Nick Dimiduk
>Assignee: Nick Dimiduk
> Attachments: 2034.patch
>
>
> Seems our list of precommit branches no longer matches the valid branch names.
> {noformat}
> BRANCH_NAMES="3.0 3.2 4.0.1 4.2 4.3 4.x-HBase-0.98 master"
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PHOENIX-1968) Phoenix-Spark: Should support saving arrays
[ https://issues.apache.org/jira/browse/PHOENIX-1968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14582370#comment-14582370 ] maghamravikiran commented on PHOENIX-1968: -- Thanks [~jmahonin] Working on this right now. > Phoenix-Spark: Should support saving arrays > --- > > Key: PHOENIX-1968 > URL: https://issues.apache.org/jira/browse/PHOENIX-1968 > Project: Phoenix > Issue Type: Bug >Reporter: Josh Mahonin >Assignee: Josh Mahonin > Attachments: PHOENIX-1968.patch > > > At present, we only use 'setObject' on the PreparedStatement when writing > back to Phoenix. This patch allows calling 'setArray' with the appropriate > sql base type when an array is passed in as a column value. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PHOENIX-2036) PhoenixConfigurationUtil should provide a pre-normalize table name to PhoenixRuntime
Siddhi Mehta created PHOENIX-2036: - Summary: PhoenixConfigurationUtil should provide a pre-normalize table name to PhoenixRuntime Key: PHOENIX-2036 URL: https://issues.apache.org/jira/browse/PHOENIX-2036 Project: Phoenix Issue Type: Bug Reporter: Siddhi Mehta Priority: Minor I was trying a basic store using PhoenixHBaseStorage and ran into some issues with it complaining about TableNotFoundException. The table(CUSTOM_ENTITY."z02") in question exists. Looking at the stacktrace I think its likely related to the change in PHOENIX-1682 where phoenix runtime expects a pre-normalized table name. We need to update PhoenixConfigurationUtil.getSelectColumnMetadataList(Configuration) be pass a pre-normalized table. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-2021) Implement ARRAY_CAT built in function
[ https://issues.apache.org/jira/browse/PHOENIX-2021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14582340#comment-14582340 ] James Taylor commented on PHOENIX-2021: --- Creating a PhoenixArray is expensive because it means deserializing and then re-serializing, so I think we should avoid it. We may need better abstraction for operating on the array in its byte format to simplify the code (and increase code reuse). > Implement ARRAY_CAT built in function > - > > Key: PHOENIX-2021 > URL: https://issues.apache.org/jira/browse/PHOENIX-2021 > Project: Phoenix > Issue Type: Sub-task >Reporter: Dumindu Buddhika >Assignee: Dumindu Buddhika > Attachments: PHOENIX-2021.patch > > > Ex: > ARRAY_CAT(ARRAY[2, 3, 4], ARRAY[4, 5, 6]) = ARRAY[2,3,4,4,5,6] > ARRAY_CAT(ARRAY["a", "b"], ARRAY["c", "d"]) = ARRAY["a", "b", "c", "d"] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-2021) Implement ARRAY_CAT built in function
[ https://issues.apache.org/jira/browse/PHOENIX-2021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14582295#comment-14582295 ] ramkrishna.s.vasudevan commented on PHOENIX-2021: - [~giacomotaylor] Do you think it is better to create two Phoenix Array from the given expression - create a new Phoenix Array with both the elements and call the existing toBytes to serialize it? The changes here are bit complicated - anyway am half way in reviewing them. [~Dumindux] But still one problem could be to get access to that Phoenix Array from the Array expression. > Implement ARRAY_CAT built in function > - > > Key: PHOENIX-2021 > URL: https://issues.apache.org/jira/browse/PHOENIX-2021 > Project: Phoenix > Issue Type: Sub-task >Reporter: Dumindu Buddhika >Assignee: Dumindu Buddhika > Attachments: PHOENIX-2021.patch > > > Ex: > ARRAY_CAT(ARRAY[2, 3, 4], ARRAY[4, 5, 6]) = ARRAY[2,3,4,4,5,6] > ARRAY_CAT(ARRAY["a", "b"], ARRAY["c", "d"]) = ARRAY["a", "b", "c", "d"] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (PHOENIX-1968) Phoenix-Spark: Should support saving arrays
[ https://issues.apache.org/jira/browse/PHOENIX-1968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14582239#comment-14582239 ] Josh Mahonin edited comment on PHOENIX-1968 at 6/11/15 5:13 PM: Updated patch for current master. It looks like the old one wasn't applying cleanly - not sure why. Despite some weird output from 'mvn verify' (RpcServer.reader output), the tests pass. was (Author: jmahonin): Updated patch for current master > Phoenix-Spark: Should support saving arrays > --- > > Key: PHOENIX-1968 > URL: https://issues.apache.org/jira/browse/PHOENIX-1968 > Project: Phoenix > Issue Type: Bug >Reporter: Josh Mahonin >Assignee: Josh Mahonin > Attachments: PHOENIX-1968.patch > > > At present, we only use 'setObject' on the PreparedStatement when writing > back to Phoenix. This patch allows calling 'setArray' with the appropriate > sql base type when an array is passed in as a column value. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PHOENIX-1968) Phoenix-Spark: Should support saving arrays
[ https://issues.apache.org/jira/browse/PHOENIX-1968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Mahonin updated PHOENIX-1968: -- Attachment: PHOENIX-1968.patch Updated patch for current master > Phoenix-Spark: Should support saving arrays > --- > > Key: PHOENIX-1968 > URL: https://issues.apache.org/jira/browse/PHOENIX-1968 > Project: Phoenix > Issue Type: Bug >Reporter: Josh Mahonin >Assignee: Josh Mahonin > Attachments: PHOENIX-1968.patch > > > At present, we only use 'setObject' on the PreparedStatement when writing > back to Phoenix. This patch allows calling 'setArray' with the appropriate > sql base type when an array is passed in as a column value. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PHOENIX-1968) Phoenix-Spark: Should support saving arrays
[ https://issues.apache.org/jira/browse/PHOENIX-1968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Mahonin updated PHOENIX-1968: -- Attachment: (was: PHOENIX-1968.patch) > Phoenix-Spark: Should support saving arrays > --- > > Key: PHOENIX-1968 > URL: https://issues.apache.org/jira/browse/PHOENIX-1968 > Project: Phoenix > Issue Type: Bug >Reporter: Josh Mahonin >Assignee: Josh Mahonin > > At present, we only use 'setObject' on the PreparedStatement when writing > back to Phoenix. This patch allows calling 'setArray' with the appropriate > sql base type when an array is passed in as a column value. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PHOENIX-2032) psql.py is broken after PHOENIX-2013
[
https://issues.apache.org/jira/browse/PHOENIX-2032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Dimiduk updated PHOENIX-2032:
--
Attachment: 2032.patch
You're correct -- I omitted one detail, which is that I had applied this patch
to remove pqs from the assembly dependencies.
My output is
{noformat}
$ jar -tf phoenix-assembly/target/phoenix-4.4.0-HBase-1.0-client.jar | grep
queryserver | wc -l
0
{noformat}
> psql.py is broken after PHOENIX-2013
>
>
> Key: PHOENIX-2032
> URL: https://issues.apache.org/jira/browse/PHOENIX-2032
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 5.0.0, 4.5.0, 4.4.1
>Reporter: Sergio Peleato
>Assignee: Nick Dimiduk
>Priority: Blocker
> Fix For: 5.0.0, 4.5.0, 4.4.1
>
> Attachments: 2032.patch, PHOENIX-2032.00.patch
>
>
> psql is no longer able to load the phoenix driver after PHOENIX-2013.
> {noformat}
> $ ./bin/psql.py localhost examples/WEB_STAT.sql
>
>
> java.sql.SQLException: No suitable driver found for jdbc:phoenix:localhost
> at java.sql.DriverManager.getConnection(DriverManager.java:596)
> at java.sql.DriverManager.getConnection(DriverManager.java:187)
> at
> org.apache.phoenix.util.PhoenixRuntime.main(PhoenixRuntime.java:183)
> {noformat}
> Hat-tip to [~chrajeshbab...@gmail.com] for tracking down the breaking change.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (PHOENIX-1859) Implement PhoenixLimit in Phoenix/Calcite Integration
[ https://issues.apache.org/jira/browse/PHOENIX-1859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maryann Xue resolved PHOENIX-1859. -- Resolution: Fixed > Implement PhoenixLimit in Phoenix/Calcite Integration > - > > Key: PHOENIX-1859 > URL: https://issues.apache.org/jira/browse/PHOENIX-1859 > Project: Phoenix > Issue Type: Sub-task >Reporter: Maryann Xue >Assignee: Maryann Xue > Original Estimate: 72h > Remaining Estimate: 72h > > Limit is represented as a Sort RelNode in Calcite. We will do sort and limit > together if sort spec is present (see PHOENIX-1858). Otherwise we will have a > standalone PhoenixLimit, for which more aggressive optimization rules can be > applied than for PhoenixSort. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-1968) Phoenix-Spark: Should support saving arrays
[ https://issues.apache.org/jira/browse/PHOENIX-1968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14581948#comment-14581948 ] Josh Mahonin commented on PHOENIX-1968: --- [~maghamraviki...@gmail.com] Any updates on this? Thanks! > Phoenix-Spark: Should support saving arrays > --- > > Key: PHOENIX-1968 > URL: https://issues.apache.org/jira/browse/PHOENIX-1968 > Project: Phoenix > Issue Type: Bug >Reporter: Josh Mahonin >Assignee: Josh Mahonin > Attachments: PHOENIX-1968.patch > > > At present, we only use 'setObject' on the PreparedStatement when writing > back to Phoenix. This patch allows calling 'setArray' with the appropriate > sql base type when an array is passed in as a column value. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-1816) Add markdown page on Phoenix website describing how to use Spark integration
[ https://issues.apache.org/jira/browse/PHOENIX-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14581942#comment-14581942 ] Josh Mahonin commented on PHOENIX-1816: --- Updated this PR to merge to master with updated Spark documentation. The updated instructions include adding the client JAR to the spark classpath, instead of attempting to bundle in a spark jobs JAR. Also attached the README.md, in case we want to update the website as well. > Add markdown page on Phoenix website describing how to use Spark integration > > > Key: PHOENIX-1816 > URL: https://issues.apache.org/jira/browse/PHOENIX-1816 > Project: Phoenix > Issue Type: Sub-task >Reporter: James Taylor >Assignee: Josh Mahonin > Fix For: 5.0.0, 4.4.0 > > Attachments: README.md > > > Now that we have some nifty integration with Spark, we should add a markdown > page to our site (http://phoenix.apache.org/), with a link in the Using menu > that describes how to use it. > See http://phoenix.apache.org/building_website.html for how to modify the the > website (in lives in svn). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PHOENIX-1816) Add markdown page on Phoenix website describing how to use Spark integration
[ https://issues.apache.org/jira/browse/PHOENIX-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Mahonin updated PHOENIX-1816: -- Attachment: README.md > Add markdown page on Phoenix website describing how to use Spark integration > > > Key: PHOENIX-1816 > URL: https://issues.apache.org/jira/browse/PHOENIX-1816 > Project: Phoenix > Issue Type: Sub-task >Reporter: James Taylor >Assignee: Josh Mahonin > Fix For: 5.0.0, 4.4.0 > > Attachments: README.md > > > Now that we have some nifty integration with Spark, we should add a markdown > page to our site (http://phoenix.apache.org/), with a link in the Using menu > that describes how to use it. > See http://phoenix.apache.org/building_website.html for how to modify the the > website (in lives in svn). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PHOENIX-1816) Add markdown page on Phoenix website describing how to use Spark integration
[ https://issues.apache.org/jira/browse/PHOENIX-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Mahonin updated PHOENIX-1816: -- Attachment: (was: README.md) > Add markdown page on Phoenix website describing how to use Spark integration > > > Key: PHOENIX-1816 > URL: https://issues.apache.org/jira/browse/PHOENIX-1816 > Project: Phoenix > Issue Type: Sub-task >Reporter: James Taylor >Assignee: Josh Mahonin > Fix For: 5.0.0, 4.4.0 > > > Now that we have some nifty integration with Spark, we should add a markdown > page to our site (http://phoenix.apache.org/), with a link in the Using menu > that describes how to use it. > See http://phoenix.apache.org/building_website.html for how to modify the the > website (in lives in svn). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-2032) psql.py is broken after PHOENIX-2013
[
https://issues.apache.org/jira/browse/PHOENIX-2032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14581565#comment-14581565
]
Gabriel Reid commented on PHOENIX-2032:
---
[~ndimiduk] I just took another quick look at this, and it seems that
phoenix-queryserver-client is being included in the client jar, but its
transitive dependencies (i.e. Calcite) aren't being pulled in, which is what
leads to this issue. I guess that's also how the reference to the Calcite
driver and the queryserver driver are also being added to the META-INF/services
file.
{code}
$ jar tf phoenix-4.5.0-SNAPSHOT-client.jar | grep queryserver
org/apache/phoenix/queryserver/
org/apache/phoenix/queryserver/server/
org/apache/phoenix/queryserver/server/Main.class
org/apache/phoenix/queryserver/server/PhoenixMetaFactory.class
org/apache/phoenix/queryserver/server/PhoenixMetaFactoryImpl.class
org/apache/phoenix/queryserver/client/
org/apache/phoenix/queryserver/client/Driver.class
org/apache/phoenix/queryserver/client/ThinClientUtil.class
$ jar tf phoenix-4.5.0-SNAPSHOT-client.jar | grep calcite
(no output)
{code}
Is there any reason that phoenix-queryserver-client is being included in the
phoenix-client jar? I would think that it's just a matter of excluding it in
the assembly descriptors and that should fix things.
> psql.py is broken after PHOENIX-2013
>
>
> Key: PHOENIX-2032
> URL: https://issues.apache.org/jira/browse/PHOENIX-2032
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 5.0.0, 4.5.0, 4.4.1
>Reporter: Sergio Peleato
>Assignee: Nick Dimiduk
>Priority: Blocker
> Fix For: 5.0.0, 4.5.0, 4.4.1
>
> Attachments: PHOENIX-2032.00.patch
>
>
> psql is no longer able to load the phoenix driver after PHOENIX-2013.
> {noformat}
> $ ./bin/psql.py localhost examples/WEB_STAT.sql
>
>
> java.sql.SQLException: No suitable driver found for jdbc:phoenix:localhost
> at java.sql.DriverManager.getConnection(DriverManager.java:596)
> at java.sql.DriverManager.getConnection(DriverManager.java:187)
> at
> org.apache.phoenix.util.PhoenixRuntime.main(PhoenixRuntime.java:183)
> {noformat}
> Hat-tip to [~chrajeshbab...@gmail.com] for tracking down the breaking change.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
