[jira] [Commented] (PHOENIX-1367) VIEW derived from another VIEW doesn't use parent VIEW indexes

[James Taylor (JIRA)]

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

James Taylor commented on PHOENIX-1367:
---

Why is this part of the patch necessary?
{code}
-} catch (ColumnNotFoundException e) { // Ignore this index 
and continue with others
-containsAllReqdCols = false;
+} catch (ColumnNotFoundException e1) { 
+// check if the index is on a view and if so check if 
the column is present and is a view constant
+if (indexParentTable==null) {
+parentName = index.getParentName().getString();
+schemaName = 
SchemaUtil.getSchemaNameFromFullName(parentName);
+tableName = 
SchemaUtil.getTableNameFromFullName(parentName);
+parentResult = updateCache(null, schemaName, 
tableName, false, resolvedTimestamp);
+parentTable = parentResult.getTable();
+if (parentTable != null && 
parentTable.getViewType()!=null) 
+indexParentTable = parentTable;
+}
+if (indexParentTable!=null) {
+PColumn indexCol = null;
+try {
+String cf = col.getFamilyName()!=null ? 
col.getFamilyName().getString() : null;
+String cq = col.getName().getString();
+if (cf!=null) {
+indexCol = 
indexParentTable.getColumnFamily(cf).getColumn(cq);
+}
+else {
+indexCol = indexParentTable.getColumn(cq);
+}
+} catch (ColumnNotFoundException e2) { // Ignore 
this index and continue with others
+containsAllReqdCols = false;
+break;
+}
+if (indexCol.getViewConstant()==null || 
Bytes.compareTo(indexCol.getViewConstant(), col.getViewConstant())!=0) {
+containsAllReqdCols = false;
+break;
+}
+}
+else {
+// Ignore this index and continue with others
+containsAllReqdCols = false;
+}
{code}

> VIEW derived from another VIEW doesn't use parent VIEW indexes
> --
>
> Key: PHOENIX-1367
> URL: https://issues.apache.org/jira/browse/PHOENIX-1367
> Project: Phoenix
>  Issue Type: Sub-task
>Reporter: James Taylor
>Assignee: Thomas D'Silva
> Fix For: 4.9.0, 4.8.1
>
> Attachments: PHOENIX-1369-4.x-HBase-0.98-v2.patch, 
> PHOENIX-1369-4.x-HBase-0.98.patch, PHOENIX_1367.test.patch
>
>
> If a VIEW has an index and another VIEW is derived from it, the child view 
> will not use the parent view's indexes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PHOENIX-1367) VIEW derived from another VIEW doesn't use parent VIEW indexes

[Thomas D'Silva (JIRA)]

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

Thomas D'Silva updated PHOENIX-1367:

Attachment: PHOENIX-1369-4.x-HBase-0.98-v2.patch

> VIEW derived from another VIEW doesn't use parent VIEW indexes
> --
>
> Key: PHOENIX-1367
> URL: https://issues.apache.org/jira/browse/PHOENIX-1367
> Project: Phoenix
>  Issue Type: Sub-task
>Reporter: James Taylor
>Assignee: Thomas D'Silva
> Fix For: 4.9.0, 4.8.1
>
> Attachments: PHOENIX-1369-4.x-HBase-0.98-v2.patch, 
> PHOENIX-1369-4.x-HBase-0.98.patch, PHOENIX_1367.test.patch
>
>
> If a VIEW has an index and another VIEW is derived from it, the child view 
> will not use the parent view's indexes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-1367) VIEW derived from another VIEW doesn't use parent VIEW indexes

[Thomas D'Silva (JIRA)]

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

Thomas D'Silva commented on PHOENIX-1367:
-

[~jamestaylor]

Yes, it works as is. I have attached a v2 patch with the test modified to have 
a child view of the tenant view and it is able to find the index table on the 
global view.

> VIEW derived from another VIEW doesn't use parent VIEW indexes
> --
>
> Key: PHOENIX-1367
> URL: https://issues.apache.org/jira/browse/PHOENIX-1367
> Project: Phoenix
>  Issue Type: Sub-task
>Reporter: James Taylor
>Assignee: Thomas D'Silva
> Fix For: 4.9.0, 4.8.1
>
> Attachments: PHOENIX-1369-4.x-HBase-0.98.patch, 
> PHOENIX_1367.test.patch
>
>
> If a VIEW has an index and another VIEW is derived from it, the child view 
> will not use the parent view's indexes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-1367) VIEW derived from another VIEW doesn't use parent VIEW indexes

[James Taylor (JIRA)]

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

James Taylor commented on PHOENIX-1367:
---

Thanks for the patch, [~tdsilva]. The initial part of the patch looks as 
expected. This should already be recursive, in that this updateCache call will 
in turn go through addIndexesFromParentTable until you reach the physical table.
{code}
+// a view on a table will not have a parent name but will have a 
physical table name (which is the parent)
+String parentName = view.getParentName()!=null ? 
view.getParentName().getString() : view.getPhysicalName().getString();
+String schemaName = SchemaUtil.getSchemaNameFromFullName(parentName);
+String tableName = SchemaUtil.getTableNameFromFullName(parentName);
+MetaDataMutationResult parentResult = 
updateCache(connection.getTenantId(), schemaName, tableName, false, 
resolvedTimestamp);
{code}

At the deepest level of the recursion, you should have the physical table and 
view1. This should just work as it did before (ignoring bugs, which of course 
there might be). Once this returns, then you'd have view1 as the parent table 
and view2 as the child. I'm hoping the routine just does the right thing. The 
part of the patch that catches the ColumnNotFoundException and checks if 
indexParentTable==null doesn't seem right (or I don't understand it). Let's sit 
together and look closer. You might need to re-resolve view1 because it would 
have been changed during the recursive call (but not sure if that's important 
or not).

Essentially, you want to add the indexes from the parent table/view to each 
child view, all the way up the view hierarchy.

> VIEW derived from another VIEW doesn't use parent VIEW indexes
> --
>
> Key: PHOENIX-1367
> URL: https://issues.apache.org/jira/browse/PHOENIX-1367
> Project: Phoenix
>  Issue Type: Sub-task
>Reporter: James Taylor
>Assignee: Thomas D'Silva
> Fix For: 4.9.0, 4.8.1
>
> Attachments: PHOENIX-1369-4.x-HBase-0.98.patch, 
> PHOENIX_1367.test.patch
>
>
> If a VIEW has an index and another VIEW is derived from it, the child view 
> will not use the parent view's indexes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-1367) VIEW derived from another VIEW doesn't use parent VIEW indexes

[Thomas D'Silva (JIRA)]

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

Thomas D'Silva commented on PHOENIX-1367:
-

I added a WIP patch.

> VIEW derived from another VIEW doesn't use parent VIEW indexes
> --
>
> Key: PHOENIX-1367
> URL: https://issues.apache.org/jira/browse/PHOENIX-1367
> Project: Phoenix
>  Issue Type: Sub-task
>Reporter: James Taylor
>Assignee: Thomas D'Silva
> Fix For: 4.9.0, 4.8.1
>
> Attachments: PHOENIX-1369-4.x-HBase-0.98.patch, 
> PHOENIX_1367.test.patch
>
>
> If a VIEW has an index and another VIEW is derived from it, the child view 
> will not use the parent view's indexes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PHOENIX-1367) VIEW derived from another VIEW doesn't use parent VIEW indexes

[Thomas D'Silva (JIRA)]

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

Thomas D'Silva updated PHOENIX-1367:

Attachment: PHOENIX-1369-4.x-HBase-0.98.patch

> VIEW derived from another VIEW doesn't use parent VIEW indexes
> --
>
> Key: PHOENIX-1367
> URL: https://issues.apache.org/jira/browse/PHOENIX-1367
> Project: Phoenix
>  Issue Type: Sub-task
>Reporter: James Taylor
>Assignee: Thomas D'Silva
> Fix For: 4.9.0, 4.8.1
>
> Attachments: PHOENIX-1369-4.x-HBase-0.98.patch, 
> PHOENIX_1367.test.patch
>
>
> If a VIEW has an index and another VIEW is derived from it, the child view 
> will not use the parent view's indexes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (PHOENIX-2946) Projected comparison between date and timestamp columns always returns true

[James Taylor (JIRA)]

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

James Taylor edited comment on PHOENIX-2946 at 9/1/16 11:49 PM:


[~kliew] - dates, times, and timestamps may use their byte[] representation 
directly for comparison. Looks like this wasn't the case. Take a look at this 
patch. It'd be useful too to have test that compared a DATE against a TIMESTAMP 
where the difference was only the nanos part. The only way to input a nanos is 
as a bind parameter through stmt.setTimestamp(xxx, ts), after using the 
setNanos() call on the timestamp. You'd also want to test comparison of an 
UNSIGNED_TIMESTAMP with a DATE, as that's where that ugly condition I added in 
PDataType.compareTo comes into play. Though PTimestamp has a codec, it 
shouldn't be used in this case for the reason indicated by the comment. Might 
be better to remove the codec as it's deceiving - it only takes into account 
the first 8 bytes - but that leads to a number of test failures so this is 
easier/safer.

Do you want to take a crack and adding a test like that to the ones you've 
already added?


was (Author: jamestaylor):
[~kliew] - dates, times, and timestamps may use their byte[] representation 
directly for comparison. Looks like this wasn't the case. Take a look at this 
patch. It'd be useful too to have test that compared a DATE against a TIMESTAMP 
where the difference was only the nanos part. The only way to input a nanos is 
as a bind parameter through stmt.setTimestamp(xxx, ts), after using the 
setNanos() call on the timestamp.

Do you want to take a crack and adding a test like that to the ones you've 
already added?

> Projected comparison between date and timestamp columns always returns true
> ---
>
> Key: PHOENIX-2946
> URL: https://issues.apache.org/jira/browse/PHOENIX-2946
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.6.0, 4.8.0
>Reporter: Kevin Liew
>Assignee: Kevin Liew
>Priority: Minor
>  Labels: comparison, date, timestamp
> Fix For: 4.9.0, 4.8.1
>
> Attachments: PHOENIX-2946_v2.patch
>
>
> {code}
> 0: jdbc:phoenix:thin:url=http://localhost:876> create table test (dateCol 
> DATE primary key, timestampCol TIMESTAMP);
> No rows affected (2.559 seconds)
> 0: jdbc:phoenix:thin:url=http://localhost:876> upsert into test values 
> (TO_DATE('1990-01-01'), NOW());
> 1 row affected (0.255 seconds)
> 0: jdbc:phoenix:thin:url=http://localhost:876> select dateCol = timestampCol 
> from test;
> +--+
> |  DATECOL = TIMESTAMPCOL  |
> +--+
> | true |
> +--+
> 1 row selected (0.019 seconds)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PHOENIX-2946) Projected comparison between date and timestamp columns always returns true

[James Taylor (JIRA)]

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

James Taylor updated PHOENIX-2946:
--
Attachment: PHOENIX-2946_v2.patch

> Projected comparison between date and timestamp columns always returns true
> ---
>
> Key: PHOENIX-2946
> URL: https://issues.apache.org/jira/browse/PHOENIX-2946
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.6.0, 4.8.0
>Reporter: Kevin Liew
>Assignee: Kevin Liew
>Priority: Minor
>  Labels: comparison, date, timestamp
> Fix For: 4.9.0, 4.8.1
>
> Attachments: PHOENIX-2946_v2.patch
>
>
> {code}
> 0: jdbc:phoenix:thin:url=http://localhost:876> create table test (dateCol 
> DATE primary key, timestampCol TIMESTAMP);
> No rows affected (2.559 seconds)
> 0: jdbc:phoenix:thin:url=http://localhost:876> upsert into test values 
> (TO_DATE('1990-01-01'), NOW());
> 1 row affected (0.255 seconds)
> 0: jdbc:phoenix:thin:url=http://localhost:876> select dateCol = timestampCol 
> from test;
> +--+
> |  DATECOL = TIMESTAMPCOL  |
> +--+
> | true |
> +--+
> 1 row selected (0.019 seconds)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PHOENIX-2946) Projected comparison between date and timestamp columns always returns true

[James Taylor (JIRA)]

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

James Taylor updated PHOENIX-2946:
--
Attachment: (was: PHOENIX-2946_v2.patch)

> Projected comparison between date and timestamp columns always returns true
> ---
>
> Key: PHOENIX-2946
> URL: https://issues.apache.org/jira/browse/PHOENIX-2946
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.6.0, 4.8.0
>Reporter: Kevin Liew
>Assignee: Kevin Liew
>Priority: Minor
>  Labels: comparison, date, timestamp
> Fix For: 4.9.0, 4.8.1
>
>
> {code}
> 0: jdbc:phoenix:thin:url=http://localhost:876> create table test (dateCol 
> DATE primary key, timestampCol TIMESTAMP);
> No rows affected (2.559 seconds)
> 0: jdbc:phoenix:thin:url=http://localhost:876> upsert into test values 
> (TO_DATE('1990-01-01'), NOW());
> 1 row affected (0.255 seconds)
> 0: jdbc:phoenix:thin:url=http://localhost:876> select dateCol = timestampCol 
> from test;
> +--+
> |  DATECOL = TIMESTAMPCOL  |
> +--+
> | true |
> +--+
> 1 row selected (0.019 seconds)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PHOENIX-2946) Projected comparison between date and timestamp columns always returns true

[James Taylor (JIRA)]

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

James Taylor updated PHOENIX-2946:
--
Attachment: PHOENIX-2946_v2.patch

[~kliew] - dates, times, and timestamps may use their byte[] representation 
directly for comparison. Looks like this wasn't the case. Take a look at this 
patch. It'd be useful too to have test that compared a DATE against a TIMESTAMP 
where the difference was only the nanos part. The only way to input a nanos is 
as a bind parameter through stmt.setTimestamp(xxx, ts), after using the 
setNanos() call on the timestamp.

Do you want to take a crack and adding a test like that to the ones you've 
already added?

> Projected comparison between date and timestamp columns always returns true
> ---
>
> Key: PHOENIX-2946
> URL: https://issues.apache.org/jira/browse/PHOENIX-2946
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.6.0, 4.8.0
>Reporter: Kevin Liew
>Assignee: Kevin Liew
>Priority: Minor
>  Labels: comparison, date, timestamp
> Fix For: 4.9.0, 4.8.1
>
> Attachments: PHOENIX-2946_v2.patch
>
>
> {code}
> 0: jdbc:phoenix:thin:url=http://localhost:876> create table test (dateCol 
> DATE primary key, timestampCol TIMESTAMP);
> No rows affected (2.559 seconds)
> 0: jdbc:phoenix:thin:url=http://localhost:876> upsert into test values 
> (TO_DATE('1990-01-01'), NOW());
> 1 row affected (0.255 seconds)
> 0: jdbc:phoenix:thin:url=http://localhost:876> select dateCol = timestampCol 
> from test;
> +--+
> |  DATECOL = TIMESTAMPCOL  |
> +--+
> | true |
> +--+
> 1 row selected (0.019 seconds)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-3201) Implement DAYOFWEEK and DAYOFYEAR built-in functions

[Hadoop QA (JIRA)]

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

Hadoop QA commented on PHOENIX-3201:


{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  
http://issues.apache.org/jira/secure/attachment/12826709/PHOENIX-3201_4.x-HBase-0.98.patch
  against 4.x-HBase-0.98 branch at commit 
06d37e534d1e07e8206eaefb82dd7bf3f50455b0.
  ATTACHMENT ID: 12826709

{color:green}+1 @author{color}.  The patch does not contain any @author 
tags.

{color:red}-1 tests included{color}.  The patch doesn't appear to include 
any new or modified tests.
Please justify why no new tests are needed for this 
patch.
Also please list what manual steps were performed to 
verify this patch.

{color:red}-1 patch{color}.  The patch command could not apply the patch.

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

This message is automatically generated.

> Implement DAYOFWEEK and DAYOFYEAR built-in functions
> 
>
> Key: PHOENIX-3201
> URL: https://issues.apache.org/jira/browse/PHOENIX-3201
> Project: Phoenix
>  Issue Type: Bug
>Reporter: James Taylor
>Assignee: prakul agarwal
>  Labels: newbie
> Fix For: 4.9.0
>
> Attachments: PHOENIX-3201.patch, PHOENIX-3201_4.x-HBase-0.98.patch, 
> PHOENIX-3201_4.x-HBase-1.1.patch, PHOENIX-3201_master.patch
>
>
> DAYOFWEEK() as documented here: 
> https://docs.oracle.com/cd/B19188_01/doc/B15917/sqfunc.htm#i1005645
> DAYOFYEAR() as documented here: 
> https://docs.oracle.com/cd/B19188_01/doc/B15917/sqfunc.htm#i1005676



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-3201) Implement DAYOFWEEK and DAYOFYEAR built-in functions

[prakul agarwal (JIRA)]

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

prakul agarwal commented on PHOENIX-3201:
-

[~samarthjain] Have attached the patches for the said branch.

> Implement DAYOFWEEK and DAYOFYEAR built-in functions
> 
>
> Key: PHOENIX-3201
> URL: https://issues.apache.org/jira/browse/PHOENIX-3201
> Project: Phoenix
>  Issue Type: Bug
>Reporter: James Taylor
>Assignee: prakul agarwal
>  Labels: newbie
> Fix For: 4.9.0
>
> Attachments: PHOENIX-3201.patch, PHOENIX-3201_4.x-HBase-0.98.patch, 
> PHOENIX-3201_4.x-HBase-1.1.patch, PHOENIX-3201_master.patch
>
>
> DAYOFWEEK() as documented here: 
> https://docs.oracle.com/cd/B19188_01/doc/B15917/sqfunc.htm#i1005645
> DAYOFYEAR() as documented here: 
> https://docs.oracle.com/cd/B19188_01/doc/B15917/sqfunc.htm#i1005676



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PHOENIX-3201) Implement DAYOFWEEK and DAYOFYEAR built-in functions

[prakul agarwal (JIRA)]

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

prakul agarwal updated PHOENIX-3201:

Attachment: PHOENIX-3201_4.x-HBase-0.98.patch
PHOENIX-3201_4.x-HBase-1.1.patch
PHOENIX-3201_master.patch

> Implement DAYOFWEEK and DAYOFYEAR built-in functions
> 
>
> Key: PHOENIX-3201
> URL: https://issues.apache.org/jira/browse/PHOENIX-3201
> Project: Phoenix
>  Issue Type: Bug
>Reporter: James Taylor
>Assignee: prakul agarwal
>  Labels: newbie
> Fix For: 4.9.0
>
> Attachments: PHOENIX-3201.patch, PHOENIX-3201_4.x-HBase-0.98.patch, 
> PHOENIX-3201_4.x-HBase-1.1.patch, PHOENIX-3201_master.patch
>
>
> DAYOFWEEK() as documented here: 
> https://docs.oracle.com/cd/B19188_01/doc/B15917/sqfunc.htm#i1005645
> DAYOFYEAR() as documented here: 
> https://docs.oracle.com/cd/B19188_01/doc/B15917/sqfunc.htm#i1005676



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-2793) Date-time functions on null dates return no data

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on PHOENIX-2793:
-

Github user kliewkliew closed the pull request at:

https://github.com/apache/phoenix/pull/201


> Date-time functions on null dates return no data
> 
>
> Key: PHOENIX-2793
> URL: https://issues.apache.org/jira/browse/PHOENIX-2793
> Project: Phoenix
>  Issue Type: Test
>Affects Versions: 4.4.0
> Environment: HDP 2.3.4
>Reporter: Kevin Liew
>Assignee: Kevin Liew
>Priority: Minor
>  Labels: date, function, time, timestamp
>
> {code:sql}select month(at1.DATE_col5) from at1 where date_col5 is null{code}
> returns zero rows but should return one null row for each null row in 
> at1.DATE_col5



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-2474) Cannot round to a negative precision (to the left of the decimal)

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on PHOENIX-2474:
-

Github user kliewkliew closed the pull request at:

https://github.com/apache/phoenix/pull/198


> Cannot round to a negative precision (to the left of the decimal)
> -
>
> Key: PHOENIX-2474
> URL: https://issues.apache.org/jira/browse/PHOENIX-2474
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.6.0
>Reporter: Kevin Liew
>Assignee: Kevin Liew
>  Labels: function, newbie, phoenix
> Fix For: 4.9.0, 4.8.1
>
> Attachments: PHOENIX-2474.patch
>
>
> Query:
> {noformat}select ROUND(444.44, -2){noformat}
> Expected result:
> {noformat}400{noformat}
> Actual result:
> {noformat}444.44{noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-2474) Cannot round to a negative precision (to the left of the decimal)

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on PHOENIX-2474:
-

Github user kliewkliew commented on the issue:

https://github.com/apache/phoenix/pull/198
  

https://github.com/apache/phoenix/commit/b7d45ca66729ae57c0896449e36b80f4fdcafb46


> Cannot round to a negative precision (to the left of the decimal)
> -
>
> Key: PHOENIX-2474
> URL: https://issues.apache.org/jira/browse/PHOENIX-2474
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.6.0
>Reporter: Kevin Liew
>Assignee: Kevin Liew
>  Labels: function, newbie, phoenix
> Fix For: 4.9.0, 4.8.1
>
> Attachments: PHOENIX-2474.patch
>
>
> Query:
> {noformat}select ROUND(444.44, -2){noformat}
> Expected result:
> {noformat}400{noformat}
> Actual result:
> {noformat}444.44{noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] phoenix pull request #198: PHOENIX-2474 Cannot round to a negative precision...

[kliewkliew]

Github user kliewkliew closed the pull request at:

https://github.com/apache/phoenix/pull/198


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

[GitHub] phoenix issue #198: PHOENIX-2474 Cannot round to a negative precision (to th...

[kliewkliew]

Github user kliewkliew commented on the issue:

https://github.com/apache/phoenix/pull/198
  

https://github.com/apache/phoenix/commit/b7d45ca66729ae57c0896449e36b80f4fdcafb46


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

[GitHub] phoenix issue #201: PHOENIX-2793 Date-time functions on null dates return no...

[kliewkliew]

Github user kliewkliew commented on the issue:

https://github.com/apache/phoenix/pull/201
  

https://github.com/apache/phoenix/commit/06d37e534d1e07e8206eaefb82dd7bf3f50455b0


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

[GitHub] phoenix pull request #201: PHOENIX-2793 Date-time functions on null dates re...

[kliewkliew]

Github user kliewkliew closed the pull request at:

https://github.com/apache/phoenix/pull/201


---
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-3210) Exception trying to cast Double to BigDecimal in UpsertCompiler

[Hadoop QA (JIRA)]

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

Hadoop QA commented on PHOENIX-3210:


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

{color:green}+1 @author{color}.  The patch does not contain any @author 
tags.

{color:red}-1 tests included{color}.  The patch doesn't appear to include 
any new or modified tests.
Please justify why no new tests are needed for this 
patch.
Also please list what manual steps were performed to 
verify this patch.

{color:green}+1 javac{color}.  The applied patch does not increase the 
total number of javac compiler warnings.

{color:red}-1 javadoc{color}.  The javadoc tool appears to have generated 
34 warning messages.

{color:green}+1 release audit{color}.  The applied patch does not increase 
the total number of release audit warnings.

{color:red}-1 lineLengths{color}.  The patch introduces the following lines 
longer than 100:
+"CREATE TABLE IF NOT EXISTS " + tableName + " (k1 INTEGER 
NOT NULL, timestamps TIMESTAMP CONSTRAINT pk PRIMARY KEY (k1))";
+ResultSet rs = conn.createStatement().executeQuery("SELECT * from " + 
tableName + "  where now() > timestamps");
+"CREATE TABLE IF NOT EXISTS " + tableName + " (k1 INTEGER NOT 
NULL, dates DATE, timestamps TIMESTAMP, times TIME, " +
+"unsignedDates UNSIGNED_DATE, unsignedTimestamps 
UNSIGNED_TIMESTAMP, unsignedTimes UNSIGNED_TIME CONSTRAINT pk PRIMARY KEY 
(k1))";
+String dml = "UPSERT INTO " + tableName + " VALUES (1, 
TO_DATE('2004-03-01 00:10:10'), TO_TIMESTAMP('2006-04-12 00:20:20'), 
TO_TIME('2008-05-16 10:30:30'), " +
+"TO_DATE('2010-06-20 00:40:40:789', '-MM-dd 
HH:mm:ss:SSS'), TO_TIMESTAMP('2012-07-28'), TO_TIME('2015-12-25 00:50:50'))";
+dml = "UPSERT INTO " + tableName + " VALUES (2, TO_DATE('2004-03-01 
00:10:10'), TO_TIMESTAMP('2006-04-12 00:50:20'), TO_TIME('2008-05-16 
10:30:30'), " +
+"TO_DATE('2010-06-20 00:40:40:789', '-MM-dd 
HH:mm:ss:SSS'), TO_TIMESTAMP('2012-07-28'), TO_TIME('2015-12-25 00:50:50'))";
+ResultSet rs = conn.createStatement().executeQuery("SELECT k1, 
MINUTE(dates), MINUTE(times), MINUTE(unsignedDates), 
MINUTE(unsignedTimestamps), " +
+"CREATE TABLE IF NOT EXISTS " + tableName + " (k1 INTEGER NOT 
NULL, dates DATE, timestamps TIMESTAMP, times TIME CONSTRAINT pk PRIMARY KEY 
(k1))";

 {color:red}-1 core tests{color}.  The patch failed these unit tests:
 

 {color:red}-1 core zombie tests{color}.  There are 1 zombie test(s):   
at 
org.apache.hadoop.test.GenericTestUtils$SleepAnswer.answer(GenericTestUtils.java:474)
at 
org.apache.hadoop.test.GenericTestUtils$SleepAnswer.answer(GenericTestUtils.java:474)
at 
org.apache.hadoop.test.GenericTestUtils$DelayAnswer.waitForResult(GenericTestUtils.java:386)
at 
org.apache.hadoop.hdfs.server.namenode.ha.TestStandbyCheckpoints.testReadsAllowedDuringCheckpoint(TestStandbyCheckpoints.java:441)
at 
org.apache.hadoop.test.GenericTestUtils$DelayAnswer.passThrough(GenericTestUtils.java:369)
at 
org.apache.hadoop.test.GenericTestUtils$DelayAnswer.answer(GenericTestUtils.java:364)

Test results: 
https://builds.apache.org/job/PreCommit-PHOENIX-Build/550//testReport/
Javadoc warnings: 
https://builds.apache.org/job/PreCommit-PHOENIX-Build/550//artifact/patchprocess/patchJavadocWarnings.txt
Console output: 
https://builds.apache.org/job/PreCommit-PHOENIX-Build/550//console

This message is automatically generated.

> Exception trying to cast Double to BigDecimal in UpsertCompiler
> ---
>
> Key: PHOENIX-3210
> URL: https://issues.apache.org/jira/browse/PHOENIX-3210
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.7.0
>Reporter: Shehzaad Nakhoda
>Assignee: prakul agarwal
>  Labels: SFDC
> Fix For: 4.9.0, 4.8.1
>
> Attachments: PHOENIX-3210.patch, PHOENIX-3210_v2.patch
>
>
> We have an UPSERT statement that is resulting in this stack trace. 
> Unfortunately I can't get a hold of the actual Upsert statement since we 
> don't log it. 
> Cause0: java.lang.ClassCastException: java.lang.Double cannot be cast to 
> java.math.BigDecimal
>  Cause0-StackTrace: 
>   at 
> org.apache.phoenix.schema.types.PDecimal.isSizeCompatible(PDecimal.java:312)
>   at 
> org.apache.phoenix.compile.UpsertCompiler$3.execute(UpsertCompiler.java:887)
>   at 
> 

[GitHub] phoenix pull request #:

[kliewkliew]

Github user kliewkliew commented on the pull request:


https://github.com/apache/phoenix/commit/06d37e534d1e07e8206eaefb82dd7bf3f50455b0#commitcomment-18870326
  
fixes #201 


---
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-2946) Projected comparison between date and timestamp columns always returns true

[Kevin Liew (JIRA)]

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

Kevin Liew commented on PHOENIX-2946:
-

This still fails on the master branch. `PDataType::compareTo` compares `0` to 
`0` if the operands cannot agree on a coercion type. 

> Projected comparison between date and timestamp columns always returns true
> ---
>
> Key: PHOENIX-2946
> URL: https://issues.apache.org/jira/browse/PHOENIX-2946
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.6.0, 4.8.0
>Reporter: Kevin Liew
>Assignee: Kevin Liew
>Priority: Minor
>  Labels: comparison, date, timestamp
> Fix For: 4.9.0, 4.8.1
>
>
> {code}
> 0: jdbc:phoenix:thin:url=http://localhost:876> create table test (dateCol 
> DATE primary key, timestampCol TIMESTAMP);
> No rows affected (2.559 seconds)
> 0: jdbc:phoenix:thin:url=http://localhost:876> upsert into test values 
> (TO_DATE('1990-01-01'), NOW());
> 1 row affected (0.255 seconds)
> 0: jdbc:phoenix:thin:url=http://localhost:876> select dateCol = timestampCol 
> from test;
> +--+
> |  DATECOL = TIMESTAMPCOL  |
> +--+
> | true |
> +--+
> 1 row selected (0.019 seconds)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-2946) Projected comparison between date and timestamp columns always returns true

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on PHOENIX-2946:
-

Github user kliewkliew commented on the issue:

https://github.com/apache/phoenix/pull/206
  
Are some casting operations more expensive than coercion? Should the 
`isCastableTo` checks be moved to their own `else-if` branches below the 
`isCoercibleTo` checks?


> Projected comparison between date and timestamp columns always returns true
> ---
>
> Key: PHOENIX-2946
> URL: https://issues.apache.org/jira/browse/PHOENIX-2946
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.6.0, 4.8.0
>Reporter: Kevin Liew
>Assignee: Kevin Liew
>Priority: Minor
>  Labels: comparison, date, timestamp
> Fix For: 4.9.0, 4.8.1
>
>
> {code}
> 0: jdbc:phoenix:thin:url=http://localhost:876> create table test (dateCol 
> DATE primary key, timestampCol TIMESTAMP);
> No rows affected (2.559 seconds)
> 0: jdbc:phoenix:thin:url=http://localhost:876> upsert into test values 
> (TO_DATE('1990-01-01'), NOW());
> 1 row affected (0.255 seconds)
> 0: jdbc:phoenix:thin:url=http://localhost:876> select dateCol = timestampCol 
> from test;
> +--+
> |  DATECOL = TIMESTAMPCOL  |
> +--+
> | true |
> +--+
> 1 row selected (0.019 seconds)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] phoenix issue #206: PHOENIX-2946 Projected comparison between date and times...

[kliewkliew]

Github user kliewkliew commented on the issue:

https://github.com/apache/phoenix/pull/206
  
Are some casting operations more expensive than coercion? Should the 
`isCastableTo` checks be moved to their own `else-if` branches below the 
`isCoercibleTo` checks?


---
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-2946) Projected comparison between date and timestamp columns always returns true

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on PHOENIX-2946:
-

GitHub user kliewkliew opened a pull request:

https://github.com/apache/phoenix/pull/206

PHOENIX-2946 Projected comparison between date and timestamp columns …

…always returns true

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/kliewkliew/phoenix PHOENIX-2946

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/phoenix/pull/206.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 #206


commit e34704eeb97cedc16a088dd9faa67736e88a8bf4
Author: kliewkliew 
Date:   2016-08-30T15:16:50Z

Merge remote-tracking branch 'apache/master'

commit 4a1e97059d8aeed20d1c6a8512e71af50318c88d
Author: kliewkliew 
Date:   2016-08-30T15:23:53Z

PHOENIX-2946 Projected comparison between date and timestamp columns always 
returns true




> Projected comparison between date and timestamp columns always returns true
> ---
>
> Key: PHOENIX-2946
> URL: https://issues.apache.org/jira/browse/PHOENIX-2946
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.6.0, 4.8.0
>Reporter: Kevin Liew
>Assignee: Kevin Liew
>Priority: Minor
>  Labels: comparison, date, timestamp
> Fix For: 4.9.0, 4.8.1
>
>
> {code}
> 0: jdbc:phoenix:thin:url=http://localhost:876> create table test (dateCol 
> DATE primary key, timestampCol TIMESTAMP);
> No rows affected (2.559 seconds)
> 0: jdbc:phoenix:thin:url=http://localhost:876> upsert into test values 
> (TO_DATE('1990-01-01'), NOW());
> 1 row affected (0.255 seconds)
> 0: jdbc:phoenix:thin:url=http://localhost:876> select dateCol = timestampCol 
> from test;
> +--+
> |  DATECOL = TIMESTAMPCOL  |
> +--+
> | true |
> +--+
> 1 row selected (0.019 seconds)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PHOENIX-2991) Add missing documentation for functions

[Josh Elser (JIRA)]

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

Josh Elser updated PHOENIX-2991:

Description: 
In PHOENIX-2990, I noticed that we were missing some functions on the reference 
page on the website:


* GetBitFunction.java
* GetByteFunction.java
* OctetLengthFunction.java
* SetBitFunction.java
* SetByteFunction.java
* ToTimeFunction.java
* ToTimestampFunction.java

TO_TIME and TO_TIMESTAMP are probably the most heinous since we actually refer 
to them elsewere in the same document. It would be nice to make sure these are 
all documented.

  was:
In PHOENIX-2990, I noticed that we were missing some functions on the reference 
page on the website:

* DistinctCountAggregateFunction.java (the shorthand version {{DISTINCT_COUNT}} 
is missing, but {{COUNT(distinct )}} is present)
* DistinctValueAggregateFunction.java
* ExternalSqlTypeIdFunction.java
* GetBitFunction.java
* GetByteFunction.java
* OctetLengthFunction.java
* SetBitFunction.java
* SetByteFunction.java
* ToTimeFunction.java
* ToTimestampFunction.java

TO_TIME and TO_TIMESTAMP are probably the most heinous since we actually refer 
to them elsewere in the same document. It would be nice to make sure these are 
all documented.


> Add missing documentation for functions
> ---
>
> Key: PHOENIX-2991
> URL: https://issues.apache.org/jira/browse/PHOENIX-2991
> Project: Phoenix
>  Issue Type: Task
>Reporter: Josh Elser
>Assignee: Josh Elser
> Fix For: 4.9.0, 4.8.1
>
>
> In PHOENIX-2990, I noticed that we were missing some functions on the 
> reference page on the website:
> * GetBitFunction.java
> * GetByteFunction.java
> * OctetLengthFunction.java
> * SetBitFunction.java
> * SetByteFunction.java
> * ToTimeFunction.java
> * ToTimestampFunction.java
> TO_TIME and TO_TIMESTAMP are probably the most heinous since we actually 
> refer to them elsewere in the same document. It would be nice to make sure 
> these are all documented.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] phoenix pull request #206: PHOENIX-2946 Projected comparison between date an...

[kliewkliew]

GitHub user kliewkliew opened a pull request:

https://github.com/apache/phoenix/pull/206

PHOENIX-2946 Projected comparison between date and timestamp columns …

…always returns true

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/kliewkliew/phoenix PHOENIX-2946

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/phoenix/pull/206.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 #206


commit e34704eeb97cedc16a088dd9faa67736e88a8bf4
Author: kliewkliew 
Date:   2016-08-30T15:16:50Z

Merge remote-tracking branch 'apache/master'

commit 4a1e97059d8aeed20d1c6a8512e71af50318c88d
Author: kliewkliew 
Date:   2016-08-30T15:23:53Z

PHOENIX-2946 Projected comparison between date and timestamp columns always 
returns true




---
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] [Resolved] (PHOENIX-3239) test

[James Taylor (JIRA)]

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

James Taylor resolved PHOENIX-3239.
---
Resolution: Invalid

> test
> 
>
> Key: PHOENIX-3239
> URL: https://issues.apache.org/jira/browse/PHOENIX-3239
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Joe Programmer
>
> hello



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PHOENIX-2991) Add missing documentation for functions

[Josh Elser (JIRA)]

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

Josh Elser updated PHOENIX-2991:

Description: 
In PHOENIX-2990, I noticed that we were missing some functions on the reference 
page on the website:

* DistinctCountAggregateFunction.java (the shorthand version {{DISTINCT_COUNT}} 
is missing, but {{COUNT(distinct )}} is present)
* DistinctValueAggregateFunction.java
* ExternalSqlTypeIdFunction.java
* GetBitFunction.java
* GetByteFunction.java
* OctetLengthFunction.java
* SetBitFunction.java
* SetByteFunction.java
* ToTimeFunction.java
* ToTimestampFunction.java

TO_TIME and TO_TIMESTAMP are probably the most heinous since we actually refer 
to them elsewere in the same document. It would be nice to make sure these are 
all documented.

  was:
In PHOENIX-2990, I noticed that we were missing some functions on the reference 
page on the website:

* DistinctCountAggregateFunction.java (the shorthand version {{DISTINCT_COUNT}} 
is missing, but {{COUNT(distinct )}} is present)
* DistinctValueAggregateFunction.java
* ExternalSqlTypeIdFunction.java
* GetBitFunction.java
* GetByteFunction.java
* IndexStateNameFunction.java
* OctetLengthFunction.java
* SetBitFunction.java
* SetByteFunction.java
* SQLIndexTypeFunction.java
* SQLTableTypeFunction.java
* SqlTypeNameFunction.java
* SQLViewTypeFunction.java
* ToTimeFunction.java
* ToTimestampFunction.java

TO_TIME and TO_TIMESTAMP are probably the most heinous since we actually refer 
to them elsewere in the same document. It would be nice to make sure these are 
all documented.


> Add missing documentation for functions
> ---
>
> Key: PHOENIX-2991
> URL: https://issues.apache.org/jira/browse/PHOENIX-2991
> Project: Phoenix
>  Issue Type: Task
>Reporter: Josh Elser
>Assignee: Josh Elser
> Fix For: 4.9.0, 4.8.1
>
>
> In PHOENIX-2990, I noticed that we were missing some functions on the 
> reference page on the website:
> * DistinctCountAggregateFunction.java (the shorthand version 
> {{DISTINCT_COUNT}} is missing, but {{COUNT(distinct )}} is present)
> * DistinctValueAggregateFunction.java
> * ExternalSqlTypeIdFunction.java
> * GetBitFunction.java
> * GetByteFunction.java
> * OctetLengthFunction.java
> * SetBitFunction.java
> * SetByteFunction.java
> * ToTimeFunction.java
> * ToTimestampFunction.java
> TO_TIME and TO_TIMESTAMP are probably the most heinous since we actually 
> refer to them elsewere in the same document. It would be nice to make sure 
> these are all documented.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PHOENIX-2946) Projected comparison between date and timestamp columns always returns true

[Kevin Liew (JIRA)]

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

Kevin Liew updated PHOENIX-2946:

Summary: Projected comparison between date and timestamp columns always 
returns true  (was: Comparison between date and timestamp always returns true)

> Projected comparison between date and timestamp columns always returns true
> ---
>
> Key: PHOENIX-2946
> URL: https://issues.apache.org/jira/browse/PHOENIX-2946
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.6.0, 4.8.0
>Reporter: Kevin Liew
>Assignee: Kevin Liew
>Priority: Minor
>  Labels: comparison, date, timestamp
> Fix For: 4.9.0, 4.8.1
>
>
> {code}
> 0: jdbc:phoenix:thin:url=http://localhost:876> create table test (dateCol 
> DATE primary key, timestampCol TIMESTAMP);
> No rows affected (2.559 seconds)
> 0: jdbc:phoenix:thin:url=http://localhost:876> upsert into test values 
> (TO_DATE('1990-01-01'), NOW());
> 1 row affected (0.255 seconds)
> 0: jdbc:phoenix:thin:url=http://localhost:876> select dateCol = timestampCol 
> from test;
> +--+
> |  DATECOL = TIMESTAMPCOL  |
> +--+
> | true |
> +--+
> 1 row selected (0.019 seconds)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (PHOENIX-2946) Comparison between date and timestamp always returns true

[Kevin Liew (JIRA)]

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

Kevin Liew reassigned PHOENIX-2946:
---

Assignee: Kevin Liew

> Comparison between date and timestamp always returns true
> -
>
> Key: PHOENIX-2946
> URL: https://issues.apache.org/jira/browse/PHOENIX-2946
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.6.0, 4.8.0
>Reporter: Kevin Liew
>Assignee: Kevin Liew
>Priority: Minor
>  Labels: comparison, date, timestamp
> Fix For: 4.9.0, 4.8.1
>
>
> {code}
> 0: jdbc:phoenix:thin:url=http://localhost:876> create table test (dateCol 
> DATE primary key, timestampCol TIMESTAMP);
> No rows affected (2.559 seconds)
> 0: jdbc:phoenix:thin:url=http://localhost:876> upsert into test values 
> (TO_DATE('1990-01-01'), NOW());
> 1 row affected (0.255 seconds)
> 0: jdbc:phoenix:thin:url=http://localhost:876> select dateCol = timestampCol 
> from test;
> +--+
> |  DATECOL = TIMESTAMPCOL  |
> +--+
> | true |
> +--+
> 1 row selected (0.019 seconds)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (PHOENIX-3239) test

[Joe Programmer (JIRA)]

Joe Programmer created PHOENIX-3239:
---

 Summary: test
 Key: PHOENIX-3239
 URL: https://issues.apache.org/jira/browse/PHOENIX-3239
 Project: Phoenix
  Issue Type: Bug
Reporter: Joe Programmer


hello



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-3219) RuntimeExceptions should be caught and thrown as SQLException

[Shehzaad Nakhoda (JIRA)]

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

Shehzaad Nakhoda commented on PHOENIX-3219:
---

[~jamestaylor] the issue in PHOENIX-3210. We have protection in the code for 
catching SQLExceptions coming out of executeUpdate, but this issue doesn't get 
wrapped into a SQLException, defeating our attempt at debug logging 

> RuntimeExceptions should be caught and thrown as SQLException
> -
>
> Key: PHOENIX-3219
> URL: https://issues.apache.org/jira/browse/PHOENIX-3219
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.7.0
>Reporter: Shehzaad Nakhoda
>
> Guarding against SQLExceptions is how one usually defends against unexpected 
> issues in a JDBC call. It would be nice if all exceptions thrown by JDBC 
> calls (e.g. PreparedStatement.execute) would actually get caught and then 
> rethrown as SQLExceptions.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-2474) Cannot round to a negative precision (to the left of the decimal)

[Hudson (JIRA)]

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

Hudson commented on PHOENIX-2474:
-

FAILURE: Integrated in Jenkins build Phoenix-master #1379 (See 
[https://builds.apache.org/job/Phoenix-master/1379/])
PHOENIX-2474 Cannot round to a negative precision (to the left of the (samarth: 
rev b7d45ca66729ae57c0896449e36b80f4fdcafb46)
* (edit) 
phoenix-core/src/test/java/org/apache/phoenix/expression/RoundFloorCeilExpressionsTest.java
* (edit) 
phoenix-core/src/main/java/org/apache/phoenix/expression/function/RoundDecimalExpression.java


> Cannot round to a negative precision (to the left of the decimal)
> -
>
> Key: PHOENIX-2474
> URL: https://issues.apache.org/jira/browse/PHOENIX-2474
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.6.0
>Reporter: Kevin Liew
>Assignee: Kevin Liew
>  Labels: function, newbie, phoenix
> Fix For: 4.9.0, 4.8.1
>
> Attachments: PHOENIX-2474.patch
>
>
> Query:
> {noformat}select ROUND(444.44, -2){noformat}
> Expected result:
> {noformat}400{noformat}
> Actual result:
> {noformat}444.44{noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-2793) Date-time functions on null dates return no data

[Hudson (JIRA)]

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

Hudson commented on PHOENIX-2793:
-

FAILURE: Integrated in Jenkins build Phoenix-master #1379 (See 
[https://builds.apache.org/job/Phoenix-master/1379/])
PHOENIX-2793 Test case for date-time functions on null dates return no 
(samarth: rev 06d37e534d1e07e8206eaefb82dd7bf3f50455b0)
* (edit) phoenix-core/src/it/java/org/apache/phoenix/end2end/DateTimeIT.java


> Date-time functions on null dates return no data
> 
>
> Key: PHOENIX-2793
> URL: https://issues.apache.org/jira/browse/PHOENIX-2793
> Project: Phoenix
>  Issue Type: Test
>Affects Versions: 4.4.0
> Environment: HDP 2.3.4
>Reporter: Kevin Liew
>Assignee: Kevin Liew
>Priority: Minor
>  Labels: date, function, time, timestamp
>
> {code:sql}select month(at1.DATE_col5) from at1 where date_col5 is null{code}
> returns zero rows but should return one null row for each null row in 
> at1.DATE_col5



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PHOENIX-3210) Exception trying to cast Double to BigDecimal in UpsertCompiler

[prakul agarwal (JIRA)]

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

prakul agarwal updated PHOENIX-3210:

Attachment: PHOENIX-3210_v2.patch

> Exception trying to cast Double to BigDecimal in UpsertCompiler
> ---
>
> Key: PHOENIX-3210
> URL: https://issues.apache.org/jira/browse/PHOENIX-3210
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.7.0
>Reporter: Shehzaad Nakhoda
>Assignee: prakul agarwal
>  Labels: SFDC
> Fix For: 4.9.0, 4.8.1
>
> Attachments: PHOENIX-3210.patch, PHOENIX-3210_v2.patch
>
>
> We have an UPSERT statement that is resulting in this stack trace. 
> Unfortunately I can't get a hold of the actual Upsert statement since we 
> don't log it. 
> Cause0: java.lang.ClassCastException: java.lang.Double cannot be cast to 
> java.math.BigDecimal
>  Cause0-StackTrace: 
>   at 
> org.apache.phoenix.schema.types.PDecimal.isSizeCompatible(PDecimal.java:312)
>   at 
> org.apache.phoenix.compile.UpsertCompiler$3.execute(UpsertCompiler.java:887)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:335)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:323)
>   at org.apache.phoenix.call.CallRunner.run(CallRunner.java:53)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement.executeMutation(PhoenixStatement.java:321)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement.executeUpdate(PhoenixStatement.java:1274)
>   at 
> phoenix.connection.ProtectedPhoenixStatement.executeUpdate(ProtectedPhoenixStatement.java:127)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-3210) Exception trying to cast Double to BigDecimal in UpsertCompiler

[prakul agarwal (JIRA)]

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

prakul agarwal commented on PHOENIX-3210:
-

[~jamestaylor] Thanks a lot for feedback. Added a patch with all suggested 
changes.

> Exception trying to cast Double to BigDecimal in UpsertCompiler
> ---
>
> Key: PHOENIX-3210
> URL: https://issues.apache.org/jira/browse/PHOENIX-3210
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.7.0
>Reporter: Shehzaad Nakhoda
>Assignee: prakul agarwal
>  Labels: SFDC
> Fix For: 4.9.0, 4.8.1
>
> Attachments: PHOENIX-3210.patch, PHOENIX-3210_v2.patch
>
>
> We have an UPSERT statement that is resulting in this stack trace. 
> Unfortunately I can't get a hold of the actual Upsert statement since we 
> don't log it. 
> Cause0: java.lang.ClassCastException: java.lang.Double cannot be cast to 
> java.math.BigDecimal
>  Cause0-StackTrace: 
>   at 
> org.apache.phoenix.schema.types.PDecimal.isSizeCompatible(PDecimal.java:312)
>   at 
> org.apache.phoenix.compile.UpsertCompiler$3.execute(UpsertCompiler.java:887)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:335)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:323)
>   at org.apache.phoenix.call.CallRunner.run(CallRunner.java:53)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement.executeMutation(PhoenixStatement.java:321)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement.executeUpdate(PhoenixStatement.java:1274)
>   at 
> phoenix.connection.ProtectedPhoenixStatement.executeUpdate(ProtectedPhoenixStatement.java:127)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-3210) Exception trying to cast Double to BigDecimal in UpsertCompiler

[Shehzaad Nakhoda (JIRA)]

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

Shehzaad Nakhoda commented on PHOENIX-3210:
---

Thanks [~prakul]! Looking forward to getting 4.8.1 into our internal build!

[~jamestaylor] I'm pretty sure it's 4.7 (assuming that's the version used in 
SFDC App Version 202). I will @-mention you on our internal work item.



> Exception trying to cast Double to BigDecimal in UpsertCompiler
> ---
>
> Key: PHOENIX-3210
> URL: https://issues.apache.org/jira/browse/PHOENIX-3210
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.7.0
>Reporter: Shehzaad Nakhoda
>Assignee: prakul agarwal
>  Labels: SFDC
> Fix For: 4.9.0, 4.8.1
>
> Attachments: PHOENIX-3210.patch, PHOENIX-3210_v2.patch
>
>
> We have an UPSERT statement that is resulting in this stack trace. 
> Unfortunately I can't get a hold of the actual Upsert statement since we 
> don't log it. 
> Cause0: java.lang.ClassCastException: java.lang.Double cannot be cast to 
> java.math.BigDecimal
>  Cause0-StackTrace: 
>   at 
> org.apache.phoenix.schema.types.PDecimal.isSizeCompatible(PDecimal.java:312)
>   at 
> org.apache.phoenix.compile.UpsertCompiler$3.execute(UpsertCompiler.java:887)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:335)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:323)
>   at org.apache.phoenix.call.CallRunner.run(CallRunner.java:53)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement.executeMutation(PhoenixStatement.java:321)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement.executeUpdate(PhoenixStatement.java:1274)
>   at 
> phoenix.connection.ProtectedPhoenixStatement.executeUpdate(ProtectedPhoenixStatement.java:127)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (PHOENIX-3238) Clean up site build scripts

[Josh Elser (JIRA)]

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

Josh Elser resolved PHOENIX-3238.
-
Resolution: Fixed

Also removed that little tip you added to the website about removing the stuff 
by hand since build.sh takes care of this now.

> Clean up site build scripts
> ---
>
> Key: PHOENIX-3238
> URL: https://issues.apache.org/jira/browse/PHOENIX-3238
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Trivial
> Attachments: PHOENIX-3238.001.patch
>
>
> Over in PHOENIX-2990, James had mentioned a manual removal of some files on 
> disk to make the site build work as intended.
> I noticed that this was intended to be done already, but there was a typo in 
> the script.
> We can also add in a system property to prevent a dock icon from bouncing 
> during the site build on OSX.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-2793) Date-time functions on null dates return no data

[Hudson (JIRA)]

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

Hudson commented on PHOENIX-2793:
-

FAILURE: Integrated in Jenkins build Phoenix-4.8-HBase-1.2 #6 (See 
[https://builds.apache.org/job/Phoenix-4.8-HBase-1.2/6/])
PHOENIX-2793 Test case for date-time functions on null dates return no 
(samarth: rev 1a08947ba6a8206565e853f4f00c8859b2d5d1eb)
* (edit) phoenix-core/src/it/java/org/apache/phoenix/end2end/DateTimeIT.java


> Date-time functions on null dates return no data
> 
>
> Key: PHOENIX-2793
> URL: https://issues.apache.org/jira/browse/PHOENIX-2793
> Project: Phoenix
>  Issue Type: Test
>Affects Versions: 4.4.0
> Environment: HDP 2.3.4
>Reporter: Kevin Liew
>Assignee: Kevin Liew
>Priority: Minor
>  Labels: date, function, time, timestamp
>
> {code:sql}select month(at1.DATE_col5) from at1 where date_col5 is null{code}
> returns zero rows but should return one null row for each null row in 
> at1.DATE_col5



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-2474) Cannot round to a negative precision (to the left of the decimal)

[Hudson (JIRA)]

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

Hudson commented on PHOENIX-2474:
-

FAILURE: Integrated in Jenkins build Phoenix-4.8-HBase-1.2 #6 (See 
[https://builds.apache.org/job/Phoenix-4.8-HBase-1.2/6/])
PHOENIX-2474 Cannot round to a negative precision (to the left of the (samarth: 
rev f0b4b5b8fc6ed5cc9a6ae252e9923f4dda0113de)
* (edit) 
phoenix-core/src/main/java/org/apache/phoenix/expression/function/RoundDecimalExpression.java
* (edit) 
phoenix-core/src/test/java/org/apache/phoenix/expression/RoundFloorCeilExpressionsTest.java


> Cannot round to a negative precision (to the left of the decimal)
> -
>
> Key: PHOENIX-2474
> URL: https://issues.apache.org/jira/browse/PHOENIX-2474
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.6.0
>Reporter: Kevin Liew
>Assignee: Kevin Liew
>  Labels: function, newbie, phoenix
> Fix For: 4.9.0, 4.8.1
>
> Attachments: PHOENIX-2474.patch
>
>
> Query:
> {noformat}select ROUND(444.44, -2){noformat}
> Expected result:
> {noformat}400{noformat}
> Actual result:
> {noformat}444.44{noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PHOENIX-1367) VIEW derived from another VIEW doesn't use parent VIEW indexes

[Thomas D'Silva (JIRA)]

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

Thomas D'Silva updated PHOENIX-1367:

Fix Version/s: 4.9.0

> VIEW derived from another VIEW doesn't use parent VIEW indexes
> --
>
> Key: PHOENIX-1367
> URL: https://issues.apache.org/jira/browse/PHOENIX-1367
> Project: Phoenix
>  Issue Type: Sub-task
>Reporter: James Taylor
>Assignee: Thomas D'Silva
> Fix For: 4.9.0, 4.8.1
>
> Attachments: PHOENIX_1367.test.patch
>
>
> If a VIEW has an index and another VIEW is derived from it, the child view 
> will not use the parent view's indexes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-3238) Clean up site build scripts

[James Taylor (JIRA)]

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

James Taylor commented on PHOENIX-3238:
---

Cool, thanks, [~elserj]! +1

> Clean up site build scripts
> ---
>
> Key: PHOENIX-3238
> URL: https://issues.apache.org/jira/browse/PHOENIX-3238
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Trivial
> Attachments: PHOENIX-3238.001.patch
>
>
> Over in PHOENIX-2990, James had mentioned a manual removal of some files on 
> disk to make the site build work as intended.
> I noticed that this was intended to be done already, but there was a typo in 
> the script.
> We can also add in a system property to prevent a dock icon from bouncing 
> during the site build on OSX.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PHOENIX-3238) Clean up site build scripts

[Josh Elser (JIRA)]

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

Josh Elser updated PHOENIX-3238:

Attachment: (was: PHOENIX-3238.001.patch)

> Clean up site build scripts
> ---
>
> Key: PHOENIX-3238
> URL: https://issues.apache.org/jira/browse/PHOENIX-3238
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Trivial
> Attachments: PHOENIX-3238.001.patch
>
>
> Over in PHOENIX-2990, James had mentioned a manual removal of some files on 
> disk to make the site build work as intended.
> I noticed that this was intended to be done already, but there was a typo in 
> the script.
> We can also add in a system property to prevent a dock icon from bouncing 
> during the site build on OSX.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Issue Comment Deleted] (PHOENIX-3238) Clean up site build scripts

[Josh Elser (JIRA)]

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

Josh Elser updated PHOENIX-3238:

Comment: was deleted

(was: .001 Fixes the removal of site/publish/language and sets the 
-Dapple.awt.UIElement=true system property to prevent a dock icon on the h2 
build.)

> Clean up site build scripts
> ---
>
> Key: PHOENIX-3238
> URL: https://issues.apache.org/jira/browse/PHOENIX-3238
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Trivial
> Attachments: PHOENIX-3238.001.patch
>
>
> Over in PHOENIX-2990, James had mentioned a manual removal of some files on 
> disk to make the site build work as intended.
> I noticed that this was intended to be done already, but there was a typo in 
> the script.
> We can also add in a system property to prevent a dock icon from bouncing 
> during the site build on OSX.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PHOENIX-3238) Clean up site build scripts

[Josh Elser (JIRA)]

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

Josh Elser updated PHOENIX-3238:

Attachment: PHOENIX-3238.001.patch

.001 Fixes the removal of site/publish/language and sets the 
-Dapple.awt.UIElement=true system property to prevent a dock icon on the h2 
build.

> Clean up site build scripts
> ---
>
> Key: PHOENIX-3238
> URL: https://issues.apache.org/jira/browse/PHOENIX-3238
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Trivial
> Attachments: PHOENIX-3238.001.patch, PHOENIX-3238.001.patch
>
>
> Over in PHOENIX-2990, James had mentioned a manual removal of some files on 
> disk to make the site build work as intended.
> I noticed that this was intended to be done already, but there was a typo in 
> the script.
> We can also add in a system property to prevent a dock icon from bouncing 
> during the site build on OSX.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PHOENIX-3238) Clean up site build scripts

[Josh Elser (JIRA)]

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

Josh Elser updated PHOENIX-3238:

Attachment: PHOENIX-3238.001.patch

.001 Fixes the removal of site/publish/language and sets the 
-Dapple.awt.UIElement=true system property to prevent a dock icon on the h2 
build.

> Clean up site build scripts
> ---
>
> Key: PHOENIX-3238
> URL: https://issues.apache.org/jira/browse/PHOENIX-3238
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Trivial
> Attachments: PHOENIX-3238.001.patch, PHOENIX-3238.001.patch
>
>
> Over in PHOENIX-2990, James had mentioned a manual removal of some files on 
> disk to make the site build work as intended.
> I noticed that this was intended to be done already, but there was a typo in 
> the script.
> We can also add in a system property to prevent a dock icon from bouncing 
> during the site build on OSX.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-3201) Implement DAYOFWEEK and DAYOFYEAR built-in functions

[Samarth Jain (JIRA)]

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

Samarth Jain commented on PHOENIX-3201:
---

Ah, that is correct. Prakul, do upload the patches for the 4.x and master 
branches then. Make sure to use random table names in the tests you added.

> Implement DAYOFWEEK and DAYOFYEAR built-in functions
> 
>
> Key: PHOENIX-3201
> URL: https://issues.apache.org/jira/browse/PHOENIX-3201
> Project: Phoenix
>  Issue Type: Bug
>Reporter: James Taylor
>Assignee: prakul agarwal
>  Labels: newbie
> Fix For: 4.9.0
>
> Attachments: PHOENIX-3201.patch
>
>
> DAYOFWEEK() as documented here: 
> https://docs.oracle.com/cd/B19188_01/doc/B15917/sqfunc.htm#i1005645
> DAYOFYEAR() as documented here: 
> https://docs.oracle.com/cd/B19188_01/doc/B15917/sqfunc.htm#i1005676



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (PHOENIX-3238) Clean up site build scripts

[Josh Elser (JIRA)]

Josh Elser created PHOENIX-3238:
---

 Summary: Clean up site build scripts
 Key: PHOENIX-3238
 URL: https://issues.apache.org/jira/browse/PHOENIX-3238
 Project: Phoenix
  Issue Type: Bug
Reporter: Josh Elser
Assignee: Josh Elser
Priority: Trivial


Over in PHOENIX-2990, James had mentioned a manual removal of some files on 
disk to make the site build work as intended.

I noticed that this was intended to be done already, but there was a typo in 
the script.

We can also add in a system property to prevent a dock icon from bouncing 
during the site build on OSX.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-3201) Implement DAYOFWEEK and DAYOFYEAR built-in functions

[James Taylor (JIRA)]

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

James Taylor commented on PHOENIX-3201:
---

[~samarthjain] - we can't put this into 4.8 branches as it doesn't meet our 
patch release criteria. Just 4.x and master for 4.9.

> Implement DAYOFWEEK and DAYOFYEAR built-in functions
> 
>
> Key: PHOENIX-3201
> URL: https://issues.apache.org/jira/browse/PHOENIX-3201
> Project: Phoenix
>  Issue Type: Bug
>Reporter: James Taylor
>Assignee: prakul agarwal
>  Labels: newbie
> Fix For: 4.9.0
>
> Attachments: PHOENIX-3201.patch
>
>
> DAYOFWEEK() as documented here: 
> https://docs.oracle.com/cd/B19188_01/doc/B15917/sqfunc.htm#i1005645
> DAYOFYEAR() as documented here: 
> https://docs.oracle.com/cd/B19188_01/doc/B15917/sqfunc.htm#i1005676



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-3201) Implement DAYOFWEEK and DAYOFYEAR built-in functions

[Samarth Jain (JIRA)]

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

Samarth Jain commented on PHOENIX-3201:
---

[~prakul] - can you upload separate patches for the 4.8-* and 4.x-* branches. 
The 4.x* branches have DataTimeIT extending BaseHBaseManagedTimeTableReuseIT 
where as 4.8* don't. 

> Implement DAYOFWEEK and DAYOFYEAR built-in functions
> 
>
> Key: PHOENIX-3201
> URL: https://issues.apache.org/jira/browse/PHOENIX-3201
> Project: Phoenix
>  Issue Type: Bug
>Reporter: James Taylor
>Assignee: prakul agarwal
>  Labels: newbie
> Fix For: 4.9.0
>
> Attachments: PHOENIX-3201.patch
>
>
> DAYOFWEEK() as documented here: 
> https://docs.oracle.com/cd/B19188_01/doc/B15917/sqfunc.htm#i1005645
> DAYOFYEAR() as documented here: 
> https://docs.oracle.com/cd/B19188_01/doc/B15917/sqfunc.htm#i1005676



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-2793) Date-time functions on null dates return no data

[Samarth Jain (JIRA)]

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

Samarth Jain commented on PHOENIX-2793:
---

+1, committed to 4.x-* and 4.8-* branches.

> Date-time functions on null dates return no data
> 
>
> Key: PHOENIX-2793
> URL: https://issues.apache.org/jira/browse/PHOENIX-2793
> Project: Phoenix
>  Issue Type: Test
>Affects Versions: 4.4.0
> Environment: HDP 2.3.4
>Reporter: Kevin Liew
>Assignee: Kevin Liew
>Priority: Minor
>  Labels: date, function, time, timestamp
>
> {code:sql}select month(at1.DATE_col5) from at1 where date_col5 is null{code}
> returns zero rows but should return one null row for each null row in 
> at1.DATE_col5



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-3054) Counting zero null rows returns an empty result set

[James Taylor (JIRA)]

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

James Taylor commented on PHOENIX-3054:
---

I think that approach looks fine, [~an...@apache.org], but you'll need to sort 
through the failing tests:
- ProductMetricsIT.testDegenerateAggregation() I'm not sure about. 
[~julianhyde] - what happens if there's a GROUP BY but there are no groups 
(i.e. because the WHERE clause filters them all out)?
- ProductMetricsIT.testConstantFalseHaving() seems correct. With the HAVING 
clause evaluating to FALSE, there should be no rows returned. We optimize out 
the HAVING clause when possible, though, so this is a bit of an edge case.
- ViewIndexIT.testDeleteViewIndexSequences() doesn't look related to your 
change, but conveniently fell right into your hands as it looks namespace 
related. :-) Might be related to the recent change of running tests with 
generated table names, but it'd be great if you could help shed some light on 
this. FYI, [~samarthjain], [~prakul].

> Counting zero null rows returns an empty result set
> ---
>
> Key: PHOENIX-3054
> URL: https://issues.apache.org/jira/browse/PHOENIX-3054
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.7.0
>Reporter: Kevin Liew
>Assignee: Ankit Singhal
>Priority: Minor
>  Labels: count, count(*), null, sql
> Fix For: 4.8.1
>
> Attachments: PHOENIX-3054.patch
>
>
> Execute the following query on a table with zero null cells.
> {code}
> select count(*) from table where column1 = null
> {code}
> The result set should consist of one cell with the value `0` but the result 
> set is empty.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-2474) Cannot round to a negative precision (to the left of the decimal)

[Samarth Jain (JIRA)]

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

Samarth Jain commented on PHOENIX-2474:
---

+1, committed to 4.x-*, 4.8-* and master branches

> Cannot round to a negative precision (to the left of the decimal)
> -
>
> Key: PHOENIX-2474
> URL: https://issues.apache.org/jira/browse/PHOENIX-2474
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.6.0
>Reporter: Kevin Liew
>Assignee: Kevin Liew
>  Labels: function, newbie, phoenix
> Fix For: 4.9.0, 4.8.1
>
> Attachments: PHOENIX-2474.patch
>
>
> Query:
> {noformat}select ROUND(444.44, -2){noformat}
> Expected result:
> {noformat}400{noformat}
> Actual result:
> {noformat}444.44{noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-2990) Ensure documentation on "time/date" datatypes/functions acknowledge lack of JDBC compliance

[Josh Elser (JIRA)]

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

Josh Elser commented on PHOENIX-2990:
-

bq. There's a long standing bug (I finally just documented the workaround 
here[1]). You need to manually remove site/publish/language/*.html before 
running ./build.sh to get the language htmls to regenerate. Would be great if 
this happened automatically.

Aha!! I'm glad I asked again :) Thanks!

> Ensure documentation on "time/date" datatypes/functions acknowledge lack of 
> JDBC compliance
> ---
>
> Key: PHOENIX-2990
> URL: https://issues.apache.org/jira/browse/PHOENIX-2990
> Project: Phoenix
>  Issue Type: Task
>Reporter: Josh Elser
>Assignee: Josh Elser
> Fix For: 4.9.0, 4.8.1
>
> Attachments: PHOENIX-2990.002.diff, PHOENIX-2990.diff
>
>
> In talking with [~speleato] about some differences in test cases between the 
> thick and thin driver and DATE/TIMESTAMP datatypes, Sergio asked me if the 
> docs were accurate on the Phoenix website about this.
> Taking a look at Data Types and Functions documentation, we don't outwardly 
> warn users that these are not 100% compliant with the JDBC APIs.
> We do have the issue tracked in JIRA in PHOENIX-868 (and more, i'm sure), but 
> it would be good to make sure the website is also forward in warning users.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-2990) Ensure documentation on "time/date" datatypes/functions acknowledge lack of JDBC compliance

[James Taylor (JIRA)]

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

James Taylor commented on PHOENIX-2990:
---

There's a long standing bug (I finally just documented the workaround here[1]). 
You need to manually remove site/publish/language/*.html before running 
./build.sh to get the language htmls to regenerate. Would be great if this 
happened automatically.

[1] https://phoenix.apache.org/building_website.html

> Ensure documentation on "time/date" datatypes/functions acknowledge lack of 
> JDBC compliance
> ---
>
> Key: PHOENIX-2990
> URL: https://issues.apache.org/jira/browse/PHOENIX-2990
> Project: Phoenix
>  Issue Type: Task
>Reporter: Josh Elser
>Assignee: Josh Elser
> Fix For: 4.9.0, 4.8.1
>
> Attachments: PHOENIX-2990.002.diff, PHOENIX-2990.diff
>
>
> In talking with [~speleato] about some differences in test cases between the 
> thick and thin driver and DATE/TIMESTAMP datatypes, Sergio asked me if the 
> docs were accurate on the Phoenix website about this.
> Taking a look at Data Types and Functions documentation, we don't outwardly 
> warn users that these are not 100% compliant with the JDBC APIs.
> We do have the issue tracked in JIRA in PHOENIX-868 (and more, i'm sure), but 
> it would be good to make sure the website is also forward in warning users.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-2990) Ensure documentation on "time/date" datatypes/functions acknowledge lack of JDBC compliance

[Josh Elser (JIRA)]

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

Josh Elser commented on PHOENIX-2990:
-

Hey [~jamestaylor], do you have any ideas why the {{merge.sh}}/{{java -jar 
merge.jar ...}} commands don't change any of the HTML files in the site/publish 
directory? I'd like to commit these, but I can't get the resulting HTML 
generated correctly and am worried that the next commit would just lose the 
changes again.

I can't seem to find the source for merge.jar to debug what's going wrong 
either..

> Ensure documentation on "time/date" datatypes/functions acknowledge lack of 
> JDBC compliance
> ---
>
> Key: PHOENIX-2990
> URL: https://issues.apache.org/jira/browse/PHOENIX-2990
> Project: Phoenix
>  Issue Type: Task
>Reporter: Josh Elser
>Assignee: Josh Elser
> Fix For: 4.9.0, 4.8.1
>
> Attachments: PHOENIX-2990.002.diff, PHOENIX-2990.diff
>
>
> In talking with [~speleato] about some differences in test cases between the 
> thick and thin driver and DATE/TIMESTAMP datatypes, Sergio asked me if the 
> docs were accurate on the Phoenix website about this.
> Taking a look at Data Types and Functions documentation, we don't outwardly 
> warn users that these are not 100% compliant with the JDBC APIs.
> We do have the issue tracked in JIRA in PHOENIX-868 (and more, i'm sure), but 
> it would be good to make sure the website is also forward in warning users.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-3226) Phoenix should have an option to fail a query that would ship large amounts of data to the client.

[James Taylor (JIRA)]

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

James Taylor commented on PHOENIX-3226:
---

Part of the reason you're seeing this is that you're using a rather primitive 
SQL client (sqlline). It's a valid request for sqlline (to fail a query that'll 
return too much data), but with Phoenix, a client would use JDBC to step 
through as many rows as they'd like. Perhaps after the tenth resultSet.next() 
call they'd stop, or perhaps there's a smarter client which pages results (but 
doing N next() calls each time). Perhaps they didn't include a limit because 
they're not sure how many rows they need to step through. The SQuirrel client 
is a little smarter in that it uses a default limit of 100.

There's a smaller category of queries, like a post aggregation on a huge join, 
which would fit into this category since they need to see all rows on the 
client before producing a result. I think as long as a query can be canceled 
while running, we should be ok.

> Phoenix should have an option to fail a query that would ship large amounts 
> of data to the client.
> --
>
> Key: PHOENIX-3226
> URL: https://issues.apache.org/jira/browse/PHOENIX-3226
> Project: Phoenix
>  Issue Type: Sub-task
>Reporter: Lars Hofhansl
>
> For many queries (merge joins, union all, some distincts, etc) Phoenix needs 
> to ship data to the client. It will happily try to do that even when that 
> requires shipping terrabytes of data to the poor client to do its final merge 
> sweep.
> Phoenix should have an option to detect these cases (from the stats and the 
> query plan), and simply - and optionally - fail the query immediately with 
> "Query too complicated", or "Query too slow", or something.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-3225) Distinct Queries are slower than expected at scale.

[James Taylor (JIRA)]

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

James Taylor commented on PHOENIX-3225:
---

Please comment on PHOENIX-418 so we have these good insights together on the 
relevant JIRA.

> Distinct Queries are slower than expected at scale.
> ---
>
> Key: PHOENIX-3225
> URL: https://issues.apache.org/jira/browse/PHOENIX-3225
> Project: Phoenix
>  Issue Type: Sub-task
>Reporter: Lars Hofhansl
>
> In our large scale tests we found that we can easily sort 400G on a few 100 
> machines, but that a simple DISTINCT would just time out. Perhaps that's 
> expected as we have to keep track of the unique values, but we should 
> investigate.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-3223) Add hadoop classpath to PQS classpath

[Alicia Ying Shu (JIRA)]

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

Alicia Ying Shu commented on PHOENIX-3223:
--

[~elserj] LGTM. Thanks.

> Add hadoop classpath to PQS classpath
> -
>
> Key: PHOENIX-3223
> URL: https://issues.apache.org/jira/browse/PHOENIX-3223
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Sergio Peleato
>Assignee: Josh Elser
> Fix For: 4.9.0, 4.8.1
>
>
> Follow-on from PHOENIX-2369: running on Microsoft's Azure Data Lake Store 
> nets some ClassNotFoundExceptions on the corresponding classes. The library 
> is available via the Hadoop installation, but we miss it because PQS isn't 
> adding the {{hadoop classpath}} like {{sqlline.py}} is (only 
> {{$HADOOP_CONF_DIR}}, oops).
> Alicia's patch on PHOENIX-2369 already did the calculation work to get the 
> classpath; just need to simply add it to PQS' classpath now.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-3054) Counting zero null rows returns an empty result set

[Julian Hyde (JIRA)]

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

Julian Hyde commented on PHOENIX-3054:
--

Right. The behavior is as if there is one group that contains zero rows. The 
count of zero rows is 0. The sum, min and max of zero rows is null. It occurs 
if you read from an empty table, or the WHERE clause removes all rows. But if 
the rows are removed after aggregation (HAVING or LIMIT) then the query returns 
0 rows.

> Counting zero null rows returns an empty result set
> ---
>
> Key: PHOENIX-3054
> URL: https://issues.apache.org/jira/browse/PHOENIX-3054
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.7.0
>Reporter: Kevin Liew
>Assignee: Ankit Singhal
>Priority: Minor
>  Labels: count, count(*), null, sql
> Fix For: 4.8.1
>
> Attachments: PHOENIX-3054.patch
>
>
> Execute the following query on a table with zero null cells.
> {code}
> select count(*) from table where column1 = null
> {code}
> The result set should consist of one cell with the value `0` but the result 
> set is empty.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-2474) Cannot round to a negative precision (to the left of the decimal)

[Kevin Liew (JIRA)]

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

Kevin Liew commented on PHOENIX-2474:
-

The tests failed due to a timeout which I think is unrelated to the patch. 

> Cannot round to a negative precision (to the left of the decimal)
> -
>
> Key: PHOENIX-2474
> URL: https://issues.apache.org/jira/browse/PHOENIX-2474
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.6.0
>Reporter: Kevin Liew
>Assignee: Kevin Liew
>  Labels: function, newbie, phoenix
> Fix For: 4.9.0, 4.8.1
>
> Attachments: PHOENIX-2474.patch
>
>
> Query:
> {noformat}select ROUND(444.44, -2){noformat}
> Expected result:
> {noformat}400{noformat}
> Actual result:
> {noformat}444.44{noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (PHOENIX-3054) Counting zero null rows returns an empty result set

[Ankit Singhal (JIRA)]

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

Ankit Singhal reassigned PHOENIX-3054:
--

Assignee: Ankit Singhal

> Counting zero null rows returns an empty result set
> ---
>
> Key: PHOENIX-3054
> URL: https://issues.apache.org/jira/browse/PHOENIX-3054
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.7.0
>Reporter: Kevin Liew
>Assignee: Ankit Singhal
>Priority: Minor
>  Labels: count, count(*), null, sql
> Fix For: 4.8.1
>
> Attachments: PHOENIX-3054.patch
>
>
> Execute the following query on a table with zero null cells.
> {code}
> select count(*) from table where column1 = null
> {code}
> The result set should consist of one cell with the value `0` but the result 
> set is empty.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-808) Create snapshot of SYSTEM.CATALOG prior to upgrade and restore on any failure

[Hudson (JIRA)]

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

Hudson commented on PHOENIX-808:


SUCCESS: Integrated in Jenkins build Phoenix-4.8-HBase-1.2 #5 (See 
[https://builds.apache.org/job/Phoenix-4.8-HBase-1.2/5/])
PHOENIX-808 Create snapshot of SYSTEM.CATALOG prior to upgrade and (samarth: 
rev 69783dd3ad11c312fcea837903bdaab6d3b16de7)
* (edit) 
phoenix-core/src/main/java/org/apache/phoenix/coprocessor/MetaDataProtocol.java
* (edit) 
phoenix-core/src/main/java/org/apache/phoenix/query/ConnectionQueryServicesImpl.java
* (edit) phoenix-core/src/main/java/org/apache/phoenix/util/UpgradeUtil.java


> Create snapshot of SYSTEM.CATALOG prior to upgrade and restore on any failure
> -
>
> Key: PHOENIX-808
> URL: https://issues.apache.org/jira/browse/PHOENIX-808
> Project: Phoenix
>  Issue Type: Task
>Reporter: James Taylor
>Assignee: Samarth Jain
> Fix For: 4.8.1
>
> Attachments: PHOENIX-808.patch, PHOENIX-808_master.patch, 
> PHOENIX-808_nowhitespace.patch, PHOENIX-808_v2.patch, 
> PHOENIX-808_v2_master.patch, PHOENIX-808_v2_nowhitespacediff.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-3236) Problem with shading apache commons on Azure.

[Hadoop QA (JIRA)]

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

Hadoop QA commented on PHOENIX-3236:


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

{color:green}+1 @author{color}.  The patch does not contain any @author 
tags.

{color:green}+0 tests included{color}.  The patch appears to be a 
documentation, build,
or dev patch that doesn't require tests.

{color:green}+1 javac{color}.  The applied patch does not increase the 
total number of javac compiler warnings.

{color:red}-1 javadoc{color}.  The javadoc tool appears to have generated 
34 warning messages.

{color:green}+1 release audit{color}.  The applied patch does not increase 
the total number of release audit warnings.

{color:green}+1 lineLengths{color}.  The patch does not introduce lines 
longer than 100

 {color:red}-1 core tests{color}.  The patch failed these unit tests:
 

Test results: 
https://builds.apache.org/job/PreCommit-PHOENIX-Build/548//testReport/
Javadoc warnings: 
https://builds.apache.org/job/PreCommit-PHOENIX-Build/548//artifact/patchprocess/patchJavadocWarnings.txt
Console output: 
https://builds.apache.org/job/PreCommit-PHOENIX-Build/548//console

This message is automatically generated.

> Problem with shading apache commons on Azure.
> -
>
> Key: PHOENIX-3236
> URL: https://issues.apache.org/jira/browse/PHOENIX-3236
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.8.0
>Reporter: Sergey Soldatov
>Assignee: Sergey Soldatov
> Attachments: PHOENIX-3236-1.patch
>
>
> When Phoenix is used on top of Azure FS, the following exception may happen 
> during execution of sqlline:
> {noformat}
> Caused by: java.lang.AbstractMethodError: 
> org.apache.hadoop.metrics2.sink.WasbAzureIaasSink.init(Lorg/apache/phoenix/shaded/org/apache/commons/configuration/SubsetConfiguration;)V
> at 
> org.apache.hadoop.metrics2.impl.MetricsConfig.getPlugin(MetricsConfig.java:199)
> at 
> org.apache.hadoop.metrics2.impl.MetricsSystemImpl.newSink(MetricsSystemImpl.java:529)
> at 
> org.apache.hadoop.metrics2.impl.MetricsSystemImpl.configureSinks(MetricsSystemImpl.java:501)
> at 
> org.apache.hadoop.metrics2.impl.MetricsSystemImpl.configure(MetricsSystemImpl.java:480)
> at 
> org.apache.hadoop.metrics2.impl.MetricsSystemImpl.start(MetricsSystemImpl.java:189)
> at 
> org.apache.hadoop.metrics2.impl.MetricsSystemImpl.init(MetricsSystemImpl.java:164)
> at 
> org.apache.hadoop.fs.azure.metrics.AzureFileSystemMetricsSystem.fileSystemStarted(AzureFileSystemMetricsSystem.java:41)
> at 
> org.apache.hadoop.fs.azure.NativeAzureFileSystem.initialize(NativeAzureFileSystem.java:1155)
> at org.apache.hadoop.fs.FileSystem.createFileSystem(FileSystem.java:2736)
> at org.apache.hadoop.fs.FileSystem.access$200(FileSystem.java:99)
> at org.apache.hadoop.fs.FileSystem$Cache.getInternal(FileSystem.java:2770)
> at org.apache.hadoop.fs.FileSystem$Cache.get(FileSystem.java:2752)
> at org.apache.hadoop.fs.FileSystem.get(FileSystem.java:386)
> at org.apache.hadoop.fs.FileSystem.get(FileSystem.java:179)
> at org.apache.hadoop.fs.FileSystem.get(FileSystem.java:370)
> at org.apache.hadoop.fs.Path.getFileSystem(Path.java:295)
> at 
> org.apache.hadoop.hbase.util.DynamicClassLoader.initTempDir(DynamicClassLoader.java:118)
> at 
> org.apache.hadoop.hbase.util.DynamicClassLoader.(DynamicClassLoader.java:98)
> at 
> org.apache.hadoop.hbase.protobuf.ProtobufUtil.(ProtobufUtil.java:249)
> at org.apache.hadoop.hbase.ClusterId.parseFrom(ClusterId.java:64)
> at 
> org.apache.hadoop.hbase.zookeeper.ZKClusterId.readClusterIdZNode(ZKClusterId.java:75)
> at 
> org.apache.hadoop.hbase.client.ZooKeeperRegistry.getClusterId(ZooKeeperRegistry.java:105)
> at 
> org.apache.hadoop.hbase.client.ConnectionManager$HConnectionImplementation.retrieveClusterId(ConnectionManager.java:886)
> at 
> org.apache.hadoop.hbase.client.ConnectionManager$HConnectionImplementation.(ConnectionManager.java:642)
> ... 32 more
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PHOENIX-3236) Problem with shading apache commons on Azure.

[Sergey Soldatov (JIRA)]

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

Sergey Soldatov updated PHOENIX-3236:
-
Attachment: PHOENIX-3236-1.patch

Quite simple patch to disable shading for apache common configuration package. 

> Problem with shading apache commons on Azure.
> -
>
> Key: PHOENIX-3236
> URL: https://issues.apache.org/jira/browse/PHOENIX-3236
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.8.0
>Reporter: Sergey Soldatov
>Assignee: Sergey Soldatov
> Attachments: PHOENIX-3236-1.patch
>
>
> When Phoenix is used on top of Azure FS, the following exception may happen 
> during execution of sqlline:
> {noformat}
> Caused by: java.lang.AbstractMethodError: 
> org.apache.hadoop.metrics2.sink.WasbAzureIaasSink.init(Lorg/apache/phoenix/shaded/org/apache/commons/configuration/SubsetConfiguration;)V
> at 
> org.apache.hadoop.metrics2.impl.MetricsConfig.getPlugin(MetricsConfig.java:199)
> at 
> org.apache.hadoop.metrics2.impl.MetricsSystemImpl.newSink(MetricsSystemImpl.java:529)
> at 
> org.apache.hadoop.metrics2.impl.MetricsSystemImpl.configureSinks(MetricsSystemImpl.java:501)
> at 
> org.apache.hadoop.metrics2.impl.MetricsSystemImpl.configure(MetricsSystemImpl.java:480)
> at 
> org.apache.hadoop.metrics2.impl.MetricsSystemImpl.start(MetricsSystemImpl.java:189)
> at 
> org.apache.hadoop.metrics2.impl.MetricsSystemImpl.init(MetricsSystemImpl.java:164)
> at 
> org.apache.hadoop.fs.azure.metrics.AzureFileSystemMetricsSystem.fileSystemStarted(AzureFileSystemMetricsSystem.java:41)
> at 
> org.apache.hadoop.fs.azure.NativeAzureFileSystem.initialize(NativeAzureFileSystem.java:1155)
> at org.apache.hadoop.fs.FileSystem.createFileSystem(FileSystem.java:2736)
> at org.apache.hadoop.fs.FileSystem.access$200(FileSystem.java:99)
> at org.apache.hadoop.fs.FileSystem$Cache.getInternal(FileSystem.java:2770)
> at org.apache.hadoop.fs.FileSystem$Cache.get(FileSystem.java:2752)
> at org.apache.hadoop.fs.FileSystem.get(FileSystem.java:386)
> at org.apache.hadoop.fs.FileSystem.get(FileSystem.java:179)
> at org.apache.hadoop.fs.FileSystem.get(FileSystem.java:370)
> at org.apache.hadoop.fs.Path.getFileSystem(Path.java:295)
> at 
> org.apache.hadoop.hbase.util.DynamicClassLoader.initTempDir(DynamicClassLoader.java:118)
> at 
> org.apache.hadoop.hbase.util.DynamicClassLoader.(DynamicClassLoader.java:98)
> at 
> org.apache.hadoop.hbase.protobuf.ProtobufUtil.(ProtobufUtil.java:249)
> at org.apache.hadoop.hbase.ClusterId.parseFrom(ClusterId.java:64)
> at 
> org.apache.hadoop.hbase.zookeeper.ZKClusterId.readClusterIdZNode(ZKClusterId.java:75)
> at 
> org.apache.hadoop.hbase.client.ZooKeeperRegistry.getClusterId(ZooKeeperRegistry.java:105)
> at 
> org.apache.hadoop.hbase.client.ConnectionManager$HConnectionImplementation.retrieveClusterId(ConnectionManager.java:886)
> at 
> org.apache.hadoop.hbase.client.ConnectionManager$HConnectionImplementation.(ConnectionManager.java:642)
> ... 32 more
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (PHOENIX-3236) Problem with shading apache commons on Azure.

[Sergey Soldatov (JIRA)]

Sergey Soldatov created PHOENIX-3236:


 Summary: Problem with shading apache commons on Azure.
 Key: PHOENIX-3236
 URL: https://issues.apache.org/jira/browse/PHOENIX-3236
 Project: Phoenix
  Issue Type: Bug
Affects Versions: 4.8.0
Reporter: Sergey Soldatov
Assignee: Sergey Soldatov


When Phoenix is used on top of Azure FS, the following exception may happen 
during execution of sqlline:
{noformat}
Caused by: java.lang.AbstractMethodError: 
org.apache.hadoop.metrics2.sink.WasbAzureIaasSink.init(Lorg/apache/phoenix/shaded/org/apache/commons/configuration/SubsetConfiguration;)V
at 
org.apache.hadoop.metrics2.impl.MetricsConfig.getPlugin(MetricsConfig.java:199)
at 
org.apache.hadoop.metrics2.impl.MetricsSystemImpl.newSink(MetricsSystemImpl.java:529)
at 
org.apache.hadoop.metrics2.impl.MetricsSystemImpl.configureSinks(MetricsSystemImpl.java:501)
at 
org.apache.hadoop.metrics2.impl.MetricsSystemImpl.configure(MetricsSystemImpl.java:480)
at 
org.apache.hadoop.metrics2.impl.MetricsSystemImpl.start(MetricsSystemImpl.java:189)
at 
org.apache.hadoop.metrics2.impl.MetricsSystemImpl.init(MetricsSystemImpl.java:164)
at 
org.apache.hadoop.fs.azure.metrics.AzureFileSystemMetricsSystem.fileSystemStarted(AzureFileSystemMetricsSystem.java:41)
at 
org.apache.hadoop.fs.azure.NativeAzureFileSystem.initialize(NativeAzureFileSystem.java:1155)
at org.apache.hadoop.fs.FileSystem.createFileSystem(FileSystem.java:2736)
at org.apache.hadoop.fs.FileSystem.access$200(FileSystem.java:99)
at org.apache.hadoop.fs.FileSystem$Cache.getInternal(FileSystem.java:2770)
at org.apache.hadoop.fs.FileSystem$Cache.get(FileSystem.java:2752)
at org.apache.hadoop.fs.FileSystem.get(FileSystem.java:386)
at org.apache.hadoop.fs.FileSystem.get(FileSystem.java:179)
at org.apache.hadoop.fs.FileSystem.get(FileSystem.java:370)
at org.apache.hadoop.fs.Path.getFileSystem(Path.java:295)
at 
org.apache.hadoop.hbase.util.DynamicClassLoader.initTempDir(DynamicClassLoader.java:118)
at 
org.apache.hadoop.hbase.util.DynamicClassLoader.(DynamicClassLoader.java:98)
at org.apache.hadoop.hbase.protobuf.ProtobufUtil.(ProtobufUtil.java:249)
at org.apache.hadoop.hbase.ClusterId.parseFrom(ClusterId.java:64)
at 
org.apache.hadoop.hbase.zookeeper.ZKClusterId.readClusterIdZNode(ZKClusterId.java:75)
at 
org.apache.hadoop.hbase.client.ZooKeeperRegistry.getClusterId(ZooKeeperRegistry.java:105)
at 
org.apache.hadoop.hbase.client.ConnectionManager$HConnectionImplementation.retrieveClusterId(ConnectionManager.java:886)
at 
org.apache.hadoop.hbase.client.ConnectionManager$HConnectionImplementation.(ConnectionManager.java:642)
... 32 more
{noformat}




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)