[jira] [Commented] (PHOENIX-4646) The data exceeds the max capacity for the data type error for valid scenarios.
[
https://issues.apache.org/jira/browse/PHOENIX-4646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16396568#comment-16396568
]
Sergey Soldatov commented on PHOENIX-4646:
--
[~jamestaylor] Well, that's getting interesting since we have to support
assigning also char to varchar and varchar to char. The postgresql thread from
PHOENIX-1145 is quite interesting (just in case - the new link to it is
https://www.postgresql.org/message-id/A737B7A37273E048B164557ADEF4A58B0579A7AB%40ntex2010a.host.magwien.gv.at
) and we need to define how we threat all combinations (char/varchar/string
constant) in terms of trailing spaces. I think that at the moment we can fix
this particular case because it's not about trailing characters, but about the
real length of the value and resolve the rest as part of PHOENIX-1145 (so to
decide whether we always trim strings or make it configurable). WDYT?
> The data exceeds the max capacity for the data type error for valid scenarios.
> --
>
> Key: PHOENIX-4646
> URL: https://issues.apache.org/jira/browse/PHOENIX-4646
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.14.0
>Reporter: Sergey Soldatov
>Assignee: Sergey Soldatov
>Priority: Major
> Fix For: 4.14.0
>
> Attachments: PHOENIX-4646.patch
>
>
> Here is an example:
> {noformat}
> create table test_trim_source(name varchar(160) primary key, id varchar(120),
> address varchar(160));
> create table test_trim_target(name varchar(160) primary key, id varchar(10),
> address
> varchar(10));
> upsert into test_trim_source values('test','test','test');
> upsert into test_trim_target select * from test_trim_source;
> {noformat}
> It fails with
> {noformat}
> Error: ERROR 206 (22003): The data exceeds the max capacity for the data
> type. value='test' columnName=ID (state=22003,code=206)
> java.sql.SQLException: ERROR 206 (22003): The data exceeds the max capacity
> for the data type. value='test' columnName=ID
> at
> org.apache.phoenix.exception.SQLExceptionCode$Factory$1.newException(SQLExceptionCode.java:489)
> at
> org.apache.phoenix.exception.SQLExceptionInfo.buildException(SQLExceptionInfo.java:150)
> at
> org.apache.phoenix.util.ServerUtil.parseRemoteException(ServerUtil.java:165)
> at
> org.apache.phoenix.util.ServerUtil.parseServerExceptionOrNull(ServerUtil.java:149)
> at
> org.apache.phoenix.util.ServerUtil.parseServerException(ServerUtil.java:116)
> at
> org.apache.phoenix.iterate.BaseResultIterators.getIterators(BaseResultIterators.java:1261)
> at
> org.apache.phoenix.iterate.BaseResultIterators.getIterators(BaseResultIterators.java:1203)
> at
> org.apache.phoenix.iterate.RoundRobinResultIterator.getIterators(RoundRobinResultIterator.java:176)
> at
> org.apache.phoenix.iterate.RoundRobinResultIterator.next(RoundRobinResultIterator.java:91)
> at
> org.apache.phoenix.compile.UpsertCompiler$ClientUpsertSelectMutationPlan.execute(UpsertCompiler.java:1300)
> at
> org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:398)
> at
> org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:381)
> at org.apache.phoenix.call.CallRunner.run(CallRunner.java:53)
> at
> org.apache.phoenix.jdbc.PhoenixStatement.executeMutation(PhoenixStatement.java:380)
> at
> org.apache.phoenix.jdbc.PhoenixStatement.executeMutation(PhoenixStatement.java:368)
> at
> org.apache.phoenix.jdbc.PhoenixStatement.execute(PhoenixStatement.java:1794)
> at sqlline.Commands.execute(Commands.java:822)
> at sqlline.Commands.sql(Commands.java:732)
> at sqlline.SqlLine.dispatch(SqlLine.java:813)
> at sqlline.SqlLine.begin(SqlLine.java:686)
> at sqlline.SqlLine.start(SqlLine.java:398)
> at sqlline.SqlLine.main(SqlLine.java:291)
> Caused by: java.sql.SQLException: ERROR 206 (22003): The data exceeds the max
> capacity for the data type. value='test' columnName=ID
> at
> org.apache.phoenix.exception.SQLExceptionCode$Factory$1.newException(SQLExceptionCode.java:489)
> at
> org.apache.phoenix.exception.SQLExceptionInfo.buildException(SQLExceptionInfo.java:150)
> at
> org.apache.phoenix.compile.UpsertCompiler.upsertSelect(UpsertCompiler.java:235)
> at
> org.apache.phoenix.compile.UpsertCompiler$UpsertingParallelIteratorFactory.mutate(UpsertCompiler.java:284)
> at
> org.apache.phoenix.compile.MutatingParallelIteratorFactory.newIterator(MutatingParallelIteratorFactory.java:59)
> at
> org.apache.phoenix.iterate.ParallelIterators$1.call(ParallelIterators.java:121)
> at
> org.apache.phoenix.iterate.ParallelIterators$1.call(ParallelIterators.java:113)
> at
[jira] [Updated] (PHOENIX-4652) When column is existed index table,drop the column,the index table is dropped.
[
https://issues.apache.org/jira/browse/PHOENIX-4652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jepson updated PHOENIX-4652:
Description:
1.When column is existed index table,drop the column,the index table is
dropped.
I hope that the column with index table is dropped,not the index table.
{code:java}
CREATE TABLE JYDW.TEST(
ID INTEGER primary key,
NAME VARCHAR(128),
AGE INTEGER,
CREDATE DATE,
CRETIME TIMESTAMP
)SALT_BUCKETS = 12, COMPRESSION='SNAPPY';
CREATE INDEX TEST_IDX ON
JYDW.TEST(
NAME,
AGE
);
alter table JYDW.TEST drop column name;
alter table JYDW.TEST add name varchar(256);
{code}
*when drop the name column, the TEST_IDX index table will be dropped.*
2.Phoenix log:
18/03/13 10:44:51 INFO client.HBaseAdmin: Started disable of JYDW:TEST_IDX
18/03/13 10:44:54 INFO client.HBaseAdmin: Disabled JYDW:TEST_IDX
18/03/13 10:45:42 INFO client.HBaseAdmin: Deleted JYDW:TEST_IDX
18/03/13 10:46:03 INFO ConnectionPool.RawMaxwellConnectionPool:
RawMaxwellConnectionPool: Destroyed connection
3.I want modify the name column, but the modify sql syntax isn't supported,
so drop first ,then add.
4.Reference:
[https://issues.apache.org/jira/browse/PHOENIX-4651|http://example.com/]
was:
*1.*When column is existed index table,drop the column,the index table is
dropped.
I hope that the column with index table is dropped,not the index table.
{code:java}
CREATE TABLE JYDW.TEST(
ID INTEGER primary key,
NAME VARCHAR(128),
AGE INTEGER,
CREDATE DATE,
CRETIME TIMESTAMP
)SALT_BUCKETS = 12, COMPRESSION='SNAPPY';
CREATE INDEX TEST_IDX ON
JYDW.TEST(
NAME,
AGE
);
alter table JYDW.TEST drop column name;
alter table JYDW.TEST add name varchar(256);
{code}
*when drop the name column, the TEST_IDX index table will be dropped.*
*2.*Phoenix log:
18/03/13 10:44:51 INFO client.HBaseAdmin: Started disable of JYDW:TEST_IDX
18/03/13 10:44:54 INFO client.HBaseAdmin: Disabled JYDW:TEST_IDX
18/03/13 10:45:42 INFO client.HBaseAdmin: Deleted JYDW:TEST_IDX
18/03/13 10:46:03 INFO ConnectionPool.RawMaxwellConnectionPool:
RawMaxwellConnectionPool: Destroyed connection
*3.*I want modify the name column, but the modify sql syntax isn't supported,
so drop first ,then add.
*4.*Reference:
[https://issues.apache.org/jira/browse/PHOENIX-4651|http://example.com/]
> When column is existed index table,drop the column,the index table is
> dropped.
> ---
>
> Key: PHOENIX-4652
> URL: https://issues.apache.org/jira/browse/PHOENIX-4652
> Project: Phoenix
> Issue Type: Wish
>Affects Versions: 4.10.0
>Reporter: Jepson
>Priority: Major
> Original Estimate: 504h
> Remaining Estimate: 504h
>
> 1.When column is existed index table,drop the column,the index table is
> dropped.
> I hope that the column with index table is dropped,not the index table.
> {code:java}
> CREATE TABLE JYDW.TEST(
> ID INTEGER primary key,
> NAME VARCHAR(128),
> AGE INTEGER,
> CREDATE DATE,
> CRETIME TIMESTAMP
> )SALT_BUCKETS = 12, COMPRESSION='SNAPPY';
> CREATE INDEX TEST_IDX ON
> JYDW.TEST(
> NAME,
> AGE
> );
> alter table JYDW.TEST drop column name;
> alter table JYDW.TEST add name varchar(256);
> {code}
> *when drop the name column, the TEST_IDX index table will be dropped.*
> 2.Phoenix log:
> 18/03/13 10:44:51 INFO client.HBaseAdmin: Started disable of JYDW:TEST_IDX
> 18/03/13 10:44:54 INFO client.HBaseAdmin: Disabled JYDW:TEST_IDX
> 18/03/13 10:45:42 INFO client.HBaseAdmin: Deleted JYDW:TEST_IDX
> 18/03/13 10:46:03 INFO ConnectionPool.RawMaxwellConnectionPool:
> RawMaxwellConnectionPool: Destroyed connection
> 3.I want modify the name column, but the modify sql syntax isn't supported,
> so drop first ,then add.
> 4.Reference:
> [https://issues.apache.org/jira/browse/PHOENIX-4651|http://example.com/]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (PHOENIX-4652) When column is existed index table,drop the column,the index table is dropped.
Jepson created PHOENIX-4652:
---
Summary: When column is existed index table,drop the column,the
index table is dropped.
Key: PHOENIX-4652
URL: https://issues.apache.org/jira/browse/PHOENIX-4652
Project: Phoenix
Issue Type: Wish
Affects Versions: 4.10.0
Reporter: Jepson
*1.*When column is existed index table,drop the column,the index table is
dropped.
I hope that the column with index table is dropped,not the index table.
{code:java}
CREATE TABLE JYDW.TEST(
ID INTEGER primary key,
NAME VARCHAR(128),
AGE INTEGER,
CREDATE DATE,
CRETIME TIMESTAMP
)SALT_BUCKETS = 12, COMPRESSION='SNAPPY';
CREATE INDEX TEST_IDX ON
JYDW.TEST(
NAME,
AGE
);
alter table JYDW.TEST drop column name;
alter table JYDW.TEST add name varchar(256);
{code}
*when drop the name column, the TEST_IDX index table will be dropped.*
*2.*Phoenix log:
18/03/13 10:44:51 INFO client.HBaseAdmin: Started disable of JYDW:TEST_IDX
18/03/13 10:44:54 INFO client.HBaseAdmin: Disabled JYDW:TEST_IDX
18/03/13 10:45:42 INFO client.HBaseAdmin: Deleted JYDW:TEST_IDX
18/03/13 10:46:03 INFO ConnectionPool.RawMaxwellConnectionPool:
RawMaxwellConnectionPool: Destroyed connection
*3.*I want modify the name column, but the modify sql syntax isn't supported,
so drop first ,then add.
*4.*Reference:
[https://issues.apache.org/jira/browse/PHOENIX-4651|http://example.com/]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (PHOENIX-4651) alter table test modify column is not support
[ https://issues.apache.org/jira/browse/PHOENIX-4651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jepson updated PHOENIX-4651: Description: Modify the column type length, is very inconvenient, drop first ,then add. Such as: alter table jydw.test drop column name; alter table jydw.test add name varchar(256); The alter table test modify column sql is not support. was: Modify the column type length, is very inconvenient, drop first ,the add. Such as: alter table jydw.test drop column name; alter table jydw.test add name varchar(256); The alter table test modify column sql is not support. > alter table test modify column is not support > - > > Key: PHOENIX-4651 > URL: https://issues.apache.org/jira/browse/PHOENIX-4651 > Project: Phoenix > Issue Type: New Feature >Affects Versions: 4.10.0 >Reporter: Jepson >Priority: Critical > Original Estimate: 504h > Remaining Estimate: 504h > > Modify the column type length, is very inconvenient, drop first ,then add. > Such as: > alter table jydw.test drop column name; > alter table jydw.test add name varchar(256); > The alter table test modify column sql is not support. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (PHOENIX-4651) alter table test modify column is not support
Jepson created PHOENIX-4651: --- Summary: alter table test modify column is not support Key: PHOENIX-4651 URL: https://issues.apache.org/jira/browse/PHOENIX-4651 Project: Phoenix Issue Type: New Feature Affects Versions: 4.10.0 Reporter: Jepson Modify the column type length, is very inconvenient, drop first ,the add. Such as: alter table jydw.test drop column name; alter table jydw.test add name varchar(256); The alter table test modify column sql is not support. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-4650) Upgrade i18n-util dependency to version 1.0.4
[ https://issues.apache.org/jira/browse/PHOENIX-4650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shehzaad Nakhoda updated PHOENIX-4650: -- Description: Currently we are on i18n-util v1.0.1 Version 1.0.2 corrects the collator used for some Chinese locales. Version 1.0.4 of i18n-util introduces ICU4J version 60.2 which has a number of improvements. was: Version 1.0.2 corrects the collator used for some Chinese locales. Version 1.0.4 of i18n-util introduces ICU4J version 60.2 which has a number of improvements. > Upgrade i18n-util dependency to version 1.0.4 > - > > Key: PHOENIX-4650 > URL: https://issues.apache.org/jira/browse/PHOENIX-4650 > Project: Phoenix > Issue Type: Improvement >Affects Versions: 4.14.0 >Reporter: Shehzaad Nakhoda >Assignee: Shehzaad Nakhoda >Priority: Major > Fix For: 4.14.0 > > Attachments: PHOENIX-4650_v1.patch > > > Currently we are on i18n-util v1.0.1 > Version 1.0.2 corrects the collator used for some Chinese locales. > Version 1.0.4 of i18n-util introduces ICU4J version 60.2 which has a number > of improvements. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (PHOENIX-4650) Upgrade i18n-util dependency to version 1.0.4
[ https://issues.apache.org/jira/browse/PHOENIX-4650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16396265#comment-16396265 ] Shehzaad Nakhoda commented on PHOENIX-4650: --- [~jamestaylor] [~tdsilva] for your consideration :-) > Upgrade i18n-util dependency to version 1.0.4 > - > > Key: PHOENIX-4650 > URL: https://issues.apache.org/jira/browse/PHOENIX-4650 > Project: Phoenix > Issue Type: Improvement >Affects Versions: 4.14.0 >Reporter: Shehzaad Nakhoda >Assignee: Shehzaad Nakhoda >Priority: Major > Fix For: 4.14.0 > > Attachments: PHOENIX-4650_v1.patch > > > Version 1.0.4 of i18n-util introduces ICU4J version 60.2 which has a number > of improvements. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-4650) Upgrade i18n-util dependency to version 1.0.4
[ https://issues.apache.org/jira/browse/PHOENIX-4650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shehzaad Nakhoda updated PHOENIX-4650: -- Description: Version 1.0.2 corrects the collator used for some Chinese locales. Version 1.0.4 of i18n-util introduces ICU4J version 60.2 which has a number of improvements. was:Version 1.0.4 of i18n-util introduces ICU4J version 60.2 which has a number of improvements. > Upgrade i18n-util dependency to version 1.0.4 > - > > Key: PHOENIX-4650 > URL: https://issues.apache.org/jira/browse/PHOENIX-4650 > Project: Phoenix > Issue Type: Improvement >Affects Versions: 4.14.0 >Reporter: Shehzaad Nakhoda >Assignee: Shehzaad Nakhoda >Priority: Major > Fix For: 4.14.0 > > Attachments: PHOENIX-4650_v1.patch > > > Version 1.0.2 corrects the collator used for some Chinese locales. > Version 1.0.4 of i18n-util introduces ICU4J version 60.2 which has a number > of improvements. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-4650) Upgrade i18n-util dependency to version 1.0.4
[ https://issues.apache.org/jira/browse/PHOENIX-4650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shehzaad Nakhoda updated PHOENIX-4650: -- Attachment: PHOENIX-4650_v1.patch > Upgrade i18n-util dependency to version 1.0.4 > - > > Key: PHOENIX-4650 > URL: https://issues.apache.org/jira/browse/PHOENIX-4650 > Project: Phoenix > Issue Type: Improvement >Affects Versions: 4.14.0 >Reporter: Shehzaad Nakhoda >Assignee: Shehzaad Nakhoda >Priority: Major > Attachments: PHOENIX-4650_v1.patch > > > Version 1.0.4 of i18n-util introduces ICU4J version 60.2 which has a number > of improvements. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (PHOENIX-4418) UPPER() and LOWER() functions should be locale-aware
[ https://issues.apache.org/jira/browse/PHOENIX-4418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16396231#comment-16396231 ] Hudson commented on PHOENIX-4418: - FAILURE: Integrated in Jenkins build Phoenix-4.x-HBase-0.98 #1831 (See [https://builds.apache.org/job/Phoenix-4.x-HBase-0.98/1831/]) PHOENIX-4418 - add locale-awareness to UPPER() and LOWER() functions (tdsilva: rev 34dd8cc72026229a3606ce21bd3fcf574c6dae11) * (edit) phoenix-core/src/main/java/org/apache/phoenix/expression/function/CollationKeyFunction.java > UPPER() and LOWER() functions should be locale-aware > > > Key: PHOENIX-4418 > URL: https://issues.apache.org/jira/browse/PHOENIX-4418 > Project: Phoenix > Issue Type: Improvement >Affects Versions: 4.13.0 >Reporter: Shehzaad Nakhoda >Assignee: Shehzaad Nakhoda >Priority: Major > Fix For: 4.14.0 > > Attachments: PHOENIX-4418_v1.patch, PHOENIX-4418_v2.patch, > PHOENIX-4418_v3.patch, upper_lower_locale_doc.patch > > > Correct conversion of a string to upper or lower case depends on Locale. > Java's upper case and lower case conversion routines allow passing in a > locale. > It should be possible to pass in a locale to UPPER() and LOWER() in Phoenix > so that locale-specific case conversion can be supported in Phoenix. > See java.lang.String#toUpperCase() -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (PHOENIX-4634) Looking up a parent index table of a tenant child view fails in BaseColumnResolver createTableRef()
[
https://issues.apache.org/jira/browse/PHOENIX-4634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16396207#comment-16396207
]
James Taylor commented on PHOENIX-4634:
---
+1
> Looking up a parent index table of a tenant child view fails in
> BaseColumnResolver createTableRef()
> ---
>
> Key: PHOENIX-4634
> URL: https://issues.apache.org/jira/browse/PHOENIX-4634
> Project: Phoenix
> Issue Type: Bug
>Reporter: Thomas D'Silva
>Assignee: Thomas D'Silva
>Priority: Major
> Fix For: 4.14.0
>
> Attachments: PHOENIX-4634-4.x-HBase-0.98.patch,
> PHOENIX-4634-v2.patch, PHOENIX-4634-v3.patch, PHOENIX-4634-v4.patch,
> PHOENIX-4634-v5.patch, PHOENIX-4634-v6.patch
>
>
> If we are looking up a parent table index of a child view , we need to
> resolve the view which will load the parent table indexes (instead of trying
> to resolve the parent table index directly).
>
> {code:java}
> org.apache.phoenix.schema.TableNotFoundException: ERROR 1012 (42M03): Table
> undefined. tableName=Schema.Schema.Index#Schma.View
> org.apache.phoenix.compile.FromCompiler$BaseColumnResolver.createTableRef(FromCompiler.java:577)
> at
> org.apache.phoenix.compile.FromCompiler$SingleTableColumnResolver.(FromCompiler.java:391)
> at
> org.apache.phoenix.compile.FromCompiler.getResolverForQuery(FromCompiler.java:228)
> at
> org.apache.phoenix.compile.FromCompiler.getResolverForQuery(FromCompiler.java:206)
> at org.apache.phoenix.optimize.QueryOptimizer.addPlan(QueryOptimizer.java:226)
> at
> org.apache.phoenix.optimize.QueryOptimizer.getApplicablePlans(QueryOptimizer.java:146)
> at
> org.apache.phoenix.optimize.QueryOptimizer.getApplicablePlans(QueryOptimizer.java:103)
> at org.apache.phoenix.compile.DeleteCompiler.compile(DeleteCompiler.java:501)
> at
> org.apache.phoenix.jdbc.PhoenixStatement$ExecutableDeleteStatement.compilePlan(PhoenixStatement.java:770)
> at
> org.apache.phoenix.jdbc.PhoenixStatement$ExecutableDeleteStatement.compilePlan(PhoenixStatement.java:758)
> at org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:386)
> at org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:376)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (PHOENIX-4640) Don't consider STATS_UPDATE_FREQ_MS_ATTRIB in TTL for server side cache
[ https://issues.apache.org/jira/browse/PHOENIX-4640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16396165#comment-16396165 ] Hudson commented on PHOENIX-4640: - FAILURE: Integrated in Jenkins build PreCommit-PHOENIX-Build #1801 (See [https://builds.apache.org/job/PreCommit-PHOENIX-Build/1801/]) PHOENIX-4640 Don't consider STATS_UPDATE_FREQ_MS_ATTRIB in TTL for (jtaylor: rev 8e73fc7dae17c93201654c72a71154eb04951f29) * (edit) phoenix-core/src/it/java/org/apache/phoenix/end2end/ParallelStatsEnabledIT.java > Don't consider STATS_UPDATE_FREQ_MS_ATTRIB in TTL for server side cache > --- > > Key: PHOENIX-4640 > URL: https://issues.apache.org/jira/browse/PHOENIX-4640 > Project: Phoenix > Issue Type: Bug >Reporter: James Taylor >Assignee: James Taylor >Priority: Major > Fix For: 4.14.0, 5.0.0 > > Attachments: PHOENIX-4640_v1.patch > > > Since stats have their own client-side cache, there's no need to consider > STATS_UPDATE_FREQ_MS_ATTRIB for the server-side TTL cache. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (PHOENIX-4418) UPPER() and LOWER() functions should be locale-aware
[ https://issues.apache.org/jira/browse/PHOENIX-4418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16396167#comment-16396167 ] Hudson commented on PHOENIX-4418: - FAILURE: Integrated in Jenkins build PreCommit-PHOENIX-Build #1801 (See [https://builds.apache.org/job/PreCommit-PHOENIX-Build/1801/]) PHOENIX-4418 - add locale-awareness to UPPER() and LOWER() functions (tdsilva: rev cc494a1ba5f65a2dd87d3e8083cf60efbf8d707a) * (edit) phoenix-core/src/main/java/org/apache/phoenix/expression/function/CollationKeyFunction.java > UPPER() and LOWER() functions should be locale-aware > > > Key: PHOENIX-4418 > URL: https://issues.apache.org/jira/browse/PHOENIX-4418 > Project: Phoenix > Issue Type: Improvement >Affects Versions: 4.13.0 >Reporter: Shehzaad Nakhoda >Assignee: Shehzaad Nakhoda >Priority: Major > Fix For: 4.14.0 > > Attachments: PHOENIX-4418_v1.patch, PHOENIX-4418_v2.patch, > PHOENIX-4418_v3.patch, upper_lower_locale_doc.patch > > > Correct conversion of a string to upper or lower case depends on Locale. > Java's upper case and lower case conversion routines allow passing in a > locale. > It should be possible to pass in a locale to UPPER() and LOWER() in Phoenix > so that locale-specific case conversion can be supported in Phoenix. > See java.lang.String#toUpperCase() -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (PHOENIX-4139) Incorrect query result for trailing duplicate GROUP BY expression
[
https://issues.apache.org/jira/browse/PHOENIX-4139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16396166#comment-16396166
]
Hudson commented on PHOENIX-4139:
-
FAILURE: Integrated in Jenkins build PreCommit-PHOENIX-Build #1801 (See
[https://builds.apache.org/job/PreCommit-PHOENIX-Build/1801/])
PHOENIX-4139 Incorrect query result for trailing duplicate GROUP BY (jtaylor:
rev 35a90e4e6ea46105983d60d845324abaf5028d99)
* (edit)
phoenix-core/src/main/java/org/apache/phoenix/schema/RowKeyValueAccessor.java
* (edit) phoenix-core/src/it/java/org/apache/phoenix/end2end/AggregateIT.java
> Incorrect query result for trailing duplicate GROUP BY expression
> --
>
> Key: PHOENIX-4139
> URL: https://issues.apache.org/jira/browse/PHOENIX-4139
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.12.0
> Environment: minicluster
>Reporter: Csaba Skrabak
>Assignee: Csaba Skrabak
>Priority: Minor
> Fix For: 4.14.0, 5.0.0
>
> Attachments: PHOENIX-4139.patch, PHOENIX-4139_v2.patch,
> PHOENIX-4139_v3.patch
>
>
> From sme-hbase hipchat room:
> Pulkit Bhardwaj·10:31
> i'm seeing a weird issue with phoenix, appreciate some thoughts
> Created a simple table in phoenix
> {noformat}
> 0: jdbc:phoenix:> create table test_select(nam VARCHAR(20), address
> VARCHAR(20), id BIGINT
> . . . . . . . . > constraint my_pk primary key (id));
> 0: jdbc:phoenix:> upsert into test_select (nam, address,id)
> values('pulkit','badaun',1);
> 0: jdbc:phoenix:> select * from test_select;
> +-+--+-+
> | NAM | ADDRESS | ID |
> +-+--+-+
> | pulkit | badaun | 1 |
> +-+--+-+
> 0: jdbc:phoenix:> select distinct 'harshit' as "test_column", nam from
> test_select;
> +--+-+
> | test_column | NAM |
> +--+-+
> | harshit | pulkit |
> +--+-+
> 0: jdbc:phoenix:> select distinct 'harshit' as "test_column", trim(nam),
> trim(nam) from test_select;
> +--+++
> | test_column | TRIM(NAM)| TRIM(NAM)|
> +--+++
> | harshit | pulkitpulkit | pulkitpulkit |
> +--+++
> {noformat}
> When I apply a trim on the nam column and use it multiple times, the output
> has the cell data duplicated!
> {noformat}
> 0: jdbc:phoenix:> select distinct 'harshit' as "test_column", trim(nam),
> trim(nam), trim(nam) from test_select;
> +--+---+---+---+
> | test_column | TRIM(NAM) | TRIM(NAM) |
> TRIM(NAM) |
> +--+---+---+---+
> | harshit | pulkitpulkitpulkit | pulkitpulkitpulkit |
> pulkitpulkitpulkit |
> +--+---+---+---+
> {noformat}
> Wondering if someone has seen this before??
> One thing to note is, if I remove the —— distinct 'harshit' as "test_column"
> —— The issue is not seen
> {noformat}
> 0: jdbc:phoenix:> select trim(nam), trim(nam), trim(nam) from test_select;
> ++++
> | TRIM(NAM) | TRIM(NAM) | TRIM(NAM) |
> ++++
> | pulkit | pulkit | pulkit |
> ++++
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (PHOENIX-4370) Surface hbase metrics from perconnection to global metrics
[
https://issues.apache.org/jira/browse/PHOENIX-4370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16396145#comment-16396145
]
Ethan Wang commented on PHOENIX-4370:
-
[~tdsilva]
> Surface hbase metrics from perconnection to global metrics
> --
>
> Key: PHOENIX-4370
> URL: https://issues.apache.org/jira/browse/PHOENIX-4370
> Project: Phoenix
> Issue Type: Bug
>Reporter: Ethan Wang
>Assignee: Ethan Wang
>Priority: Major
> Attachments: PHOENIX-4370-v1.patch
>
>
> Surface hbase metrics from perconnection to global metrics
> Currently in phoenix client side, HBASE metrics are recorded and surfaced at
> Per Connection level. PHOENIX-4370 allow it to be aggregated at global level,
> i.e., aggregate across all connections within in one JVM so that user can
> evaluate it as a stable metrics periodically.
> COUNT_RPC_CALLS("rp", "Number of RPC calls"),
> COUNT_REMOTE_RPC_CALLS("rr", "Number of remote RPC calls"),
> COUNT_MILLS_BETWEEN_NEXTS("n", "Sum of milliseconds between sequential
> next calls"),
> COUNT_NOT_SERVING_REGION_EXCEPTION("nsr", "Number of
> NotServingRegionException caught"),
> COUNT_BYTES_REGION_SERVER_RESULTS("rs", "Number of bytes in Result
> objects from region servers"),
> COUNT_BYTES_IN_REMOTE_RESULTS("rrs", "Number of bytes in Result objects
> from remote region servers"),
> COUNT_SCANNED_REGIONS("rg", "Number of regions scanned"),
> COUNT_RPC_RETRIES("rpr", "Number of RPC retries"),
> COUNT_REMOTE_RPC_RETRIES("rrr", "Number of remote RPC retries"),
> COUNT_ROWS_SCANNED("ws", "Number of rows scanned"),
> COUNT_ROWS_FILTERED("wf", "Number of rows filtered");
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (PHOENIX-4418) UPPER() and LOWER() functions should be locale-aware
[ https://issues.apache.org/jira/browse/PHOENIX-4418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16396137#comment-16396137 ] Hudson commented on PHOENIX-4418: - SUCCESS: Integrated in Jenkins build Phoenix-4.x-HBase-1.3 #59 (See [https://builds.apache.org/job/Phoenix-4.x-HBase-1.3/59/]) PHOENIX-4418 - add locale-awareness to UPPER() and LOWER() functions (tdsilva: rev a73fb08ca8f77e2d22aa81912bad054778c8ddbf) * (edit) phoenix-core/src/main/java/org/apache/phoenix/expression/function/CollationKeyFunction.java > UPPER() and LOWER() functions should be locale-aware > > > Key: PHOENIX-4418 > URL: https://issues.apache.org/jira/browse/PHOENIX-4418 > Project: Phoenix > Issue Type: Improvement >Affects Versions: 4.13.0 >Reporter: Shehzaad Nakhoda >Assignee: Shehzaad Nakhoda >Priority: Major > Fix For: 4.14.0 > > Attachments: PHOENIX-4418_v1.patch, PHOENIX-4418_v2.patch, > PHOENIX-4418_v3.patch, upper_lower_locale_doc.patch > > > Correct conversion of a string to upper or lower case depends on Locale. > Java's upper case and lower case conversion routines allow passing in a > locale. > It should be possible to pass in a locale to UPPER() and LOWER() in Phoenix > so that locale-specific case conversion can be supported in Phoenix. > See java.lang.String#toUpperCase() -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (PHOENIX-4634) Looking up a parent index table of a tenant child view fails in BaseColumnResolver createTableRef()
[
https://issues.apache.org/jira/browse/PHOENIX-4634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16396100#comment-16396100
]
Thomas D'Silva edited comment on PHOENIX-4634 at 3/12/18 9:49 PM:
--
[~jamestaylor]
Thanks for the review, I have attached a v6 patch with the feedback.
was (Author: tdsilva):
[~jamestaylor]
Thanks for the view, I have attached a v6 patch with the feedback.
> Looking up a parent index table of a tenant child view fails in
> BaseColumnResolver createTableRef()
> ---
>
> Key: PHOENIX-4634
> URL: https://issues.apache.org/jira/browse/PHOENIX-4634
> Project: Phoenix
> Issue Type: Bug
>Reporter: Thomas D'Silva
>Assignee: Thomas D'Silva
>Priority: Major
> Fix For: 4.14.0
>
> Attachments: PHOENIX-4634-4.x-HBase-0.98.patch,
> PHOENIX-4634-v2.patch, PHOENIX-4634-v3.patch, PHOENIX-4634-v4.patch,
> PHOENIX-4634-v5.patch, PHOENIX-4634-v6.patch
>
>
> If we are looking up a parent table index of a child view , we need to
> resolve the view which will load the parent table indexes (instead of trying
> to resolve the parent table index directly).
>
> {code:java}
> org.apache.phoenix.schema.TableNotFoundException: ERROR 1012 (42M03): Table
> undefined. tableName=Schema.Schema.Index#Schma.View
> org.apache.phoenix.compile.FromCompiler$BaseColumnResolver.createTableRef(FromCompiler.java:577)
> at
> org.apache.phoenix.compile.FromCompiler$SingleTableColumnResolver.(FromCompiler.java:391)
> at
> org.apache.phoenix.compile.FromCompiler.getResolverForQuery(FromCompiler.java:228)
> at
> org.apache.phoenix.compile.FromCompiler.getResolverForQuery(FromCompiler.java:206)
> at org.apache.phoenix.optimize.QueryOptimizer.addPlan(QueryOptimizer.java:226)
> at
> org.apache.phoenix.optimize.QueryOptimizer.getApplicablePlans(QueryOptimizer.java:146)
> at
> org.apache.phoenix.optimize.QueryOptimizer.getApplicablePlans(QueryOptimizer.java:103)
> at org.apache.phoenix.compile.DeleteCompiler.compile(DeleteCompiler.java:501)
> at
> org.apache.phoenix.jdbc.PhoenixStatement$ExecutableDeleteStatement.compilePlan(PhoenixStatement.java:770)
> at
> org.apache.phoenix.jdbc.PhoenixStatement$ExecutableDeleteStatement.compilePlan(PhoenixStatement.java:758)
> at org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:386)
> at org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:376)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (PHOENIX-4634) Looking up a parent index table of a tenant child view fails in BaseColumnResolver createTableRef()
[
https://issues.apache.org/jira/browse/PHOENIX-4634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16396100#comment-16396100
]
Thomas D'Silva commented on PHOENIX-4634:
-
[~jamestaylor]
Thanks for the view, I have attached a v6 patch with the feedback.
> Looking up a parent index table of a tenant child view fails in
> BaseColumnResolver createTableRef()
> ---
>
> Key: PHOENIX-4634
> URL: https://issues.apache.org/jira/browse/PHOENIX-4634
> Project: Phoenix
> Issue Type: Bug
>Reporter: Thomas D'Silva
>Assignee: Thomas D'Silva
>Priority: Major
> Fix For: 4.14.0
>
> Attachments: PHOENIX-4634-4.x-HBase-0.98.patch,
> PHOENIX-4634-v2.patch, PHOENIX-4634-v3.patch, PHOENIX-4634-v4.patch,
> PHOENIX-4634-v5.patch, PHOENIX-4634-v6.patch
>
>
> If we are looking up a parent table index of a child view , we need to
> resolve the view which will load the parent table indexes (instead of trying
> to resolve the parent table index directly).
>
> {code:java}
> org.apache.phoenix.schema.TableNotFoundException: ERROR 1012 (42M03): Table
> undefined. tableName=Schema.Schema.Index#Schma.View
> org.apache.phoenix.compile.FromCompiler$BaseColumnResolver.createTableRef(FromCompiler.java:577)
> at
> org.apache.phoenix.compile.FromCompiler$SingleTableColumnResolver.(FromCompiler.java:391)
> at
> org.apache.phoenix.compile.FromCompiler.getResolverForQuery(FromCompiler.java:228)
> at
> org.apache.phoenix.compile.FromCompiler.getResolverForQuery(FromCompiler.java:206)
> at org.apache.phoenix.optimize.QueryOptimizer.addPlan(QueryOptimizer.java:226)
> at
> org.apache.phoenix.optimize.QueryOptimizer.getApplicablePlans(QueryOptimizer.java:146)
> at
> org.apache.phoenix.optimize.QueryOptimizer.getApplicablePlans(QueryOptimizer.java:103)
> at org.apache.phoenix.compile.DeleteCompiler.compile(DeleteCompiler.java:501)
> at
> org.apache.phoenix.jdbc.PhoenixStatement$ExecutableDeleteStatement.compilePlan(PhoenixStatement.java:770)
> at
> org.apache.phoenix.jdbc.PhoenixStatement$ExecutableDeleteStatement.compilePlan(PhoenixStatement.java:758)
> at org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:386)
> at org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:376)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (PHOENIX-4634) Looking up a parent index table of a tenant child view fails in BaseColumnResolver createTableRef()
[
https://issues.apache.org/jira/browse/PHOENIX-4634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas D'Silva updated PHOENIX-4634:
Attachment: PHOENIX-4634-v6.patch
> Looking up a parent index table of a tenant child view fails in
> BaseColumnResolver createTableRef()
> ---
>
> Key: PHOENIX-4634
> URL: https://issues.apache.org/jira/browse/PHOENIX-4634
> Project: Phoenix
> Issue Type: Bug
>Reporter: Thomas D'Silva
>Assignee: Thomas D'Silva
>Priority: Major
> Fix For: 4.14.0
>
> Attachments: PHOENIX-4634-4.x-HBase-0.98.patch,
> PHOENIX-4634-v2.patch, PHOENIX-4634-v3.patch, PHOENIX-4634-v4.patch,
> PHOENIX-4634-v5.patch, PHOENIX-4634-v6.patch
>
>
> If we are looking up a parent table index of a child view , we need to
> resolve the view which will load the parent table indexes (instead of trying
> to resolve the parent table index directly).
>
> {code:java}
> org.apache.phoenix.schema.TableNotFoundException: ERROR 1012 (42M03): Table
> undefined. tableName=Schema.Schema.Index#Schma.View
> org.apache.phoenix.compile.FromCompiler$BaseColumnResolver.createTableRef(FromCompiler.java:577)
> at
> org.apache.phoenix.compile.FromCompiler$SingleTableColumnResolver.(FromCompiler.java:391)
> at
> org.apache.phoenix.compile.FromCompiler.getResolverForQuery(FromCompiler.java:228)
> at
> org.apache.phoenix.compile.FromCompiler.getResolverForQuery(FromCompiler.java:206)
> at org.apache.phoenix.optimize.QueryOptimizer.addPlan(QueryOptimizer.java:226)
> at
> org.apache.phoenix.optimize.QueryOptimizer.getApplicablePlans(QueryOptimizer.java:146)
> at
> org.apache.phoenix.optimize.QueryOptimizer.getApplicablePlans(QueryOptimizer.java:103)
> at org.apache.phoenix.compile.DeleteCompiler.compile(DeleteCompiler.java:501)
> at
> org.apache.phoenix.jdbc.PhoenixStatement$ExecutableDeleteStatement.compilePlan(PhoenixStatement.java:770)
> at
> org.apache.phoenix.jdbc.PhoenixStatement$ExecutableDeleteStatement.compilePlan(PhoenixStatement.java:758)
> at org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:386)
> at org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:376)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (PHOENIX-4624) COLLATION_KEY function cannot handle null values
[ https://issues.apache.org/jira/browse/PHOENIX-4624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16395871#comment-16395871 ] Hudson commented on PHOENIX-4624: - SUCCESS: Integrated in Jenkins build Phoenix-4.x-HBase-0.98 #1830 (See [https://builds.apache.org/job/Phoenix-4.x-HBase-0.98/1830/]) PHOENIX-4624 COLLATION_KEY function cannot handle null values (Shehzaad (jtaylor: rev 2b36fa2d7a5bb4b2d27ca704728aadf720e25afe) * (edit) phoenix-core/src/test/java/org/apache/phoenix/expression/function/CollationKeyFunctionTest.java * (edit) phoenix-core/src/main/java/org/apache/phoenix/expression/function/CollationKeyFunction.java * (edit) phoenix-core/src/it/java/org/apache/phoenix/end2end/CollationKeyFunctionIT.java > COLLATION_KEY function cannot handle null values > > > Key: PHOENIX-4624 > URL: https://issues.apache.org/jira/browse/PHOENIX-4624 > Project: Phoenix > Issue Type: Bug >Reporter: Shehzaad Nakhoda >Assignee: Shehzaad Nakhoda >Priority: Major > Fix For: 4.14.0 > > Attachments: PHOENIX-4624_v1.patch > > > COLLATION_KEY throws a NullPointerException when it encounters values that > are null. > Example: > 0: jdbc:phoenix:localhost> create table hello_table (ID DECIMAL PRIMARY KEY, > NAME VARCHAR); > No rows affected (0.323 seconds) > 0: jdbc:phoenix:localhost> upsert into hello_table VALUES(1, 'One'); > 1 row affected (0.032 seconds) > 0: jdbc:phoenix:localhost> upsert into hello_table VALUES(2, 'Two'); > 1 row affected (0.006 seconds) > 0: jdbc:phoenix:localhost> upsert into hello_table VALUES(0, NULL); > 1 row affected (0.004 seconds) > 0: jdbc:phoenix:localhost> select * from hello_table order by > collation_key(name, 'en_US'); > +--+--+ > |ID| NAME > | > +--+--+ > java.lang.RuntimeException: org.apache.phoenix.exception.PhoenixIOException: > org.apache.phoenix.exception.PhoenixIOException: > org.apache.hadoop.hbase.DoNotRetryIOException: > HELLO_TABLE,,1519258211363.5898d1758d5b82ada5b27b2a8a9fba27.: null > at > org.apache.phoenix.util.ServerUtil.createIOException(ServerUtil.java:96) > at > org.apache.phoenix.util.ServerUtil.throwIOException(ServerUtil.java:62) > at > org.apache.phoenix.iterate.NonAggregateRegionScannerFactory.getTopNScanner(NonAggregateRegionScannerFactory.java:327) > at > org.apache.phoenix.iterate.NonAggregateRegionScannerFactory.getRegionScanner(NonAggregateRegionScannerFactory.java:164) > at > org.apache.phoenix.coprocessor.ScanRegionObserver.doPostScannerOpen(ScanRegionObserver.java:72) > at > org.apache.phoenix.coprocessor.BaseScannerRegionObserver$RegionScannerHolder.overrideDelegate(BaseScannerRegionObserver.java:235) > at > org.apache.phoenix.coprocessor.BaseScannerRegionObserver$RegionScannerHolder.nextRaw(BaseScannerRegionObserver.java:286) > at > org.apache.hadoop.hbase.regionserver.HRegionServer.scan(HRegionServer.java:3361) > at > org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:32492) > at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2211) > at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:104) > at > org.apache.hadoop.hbase.ipc.RpcExecutor.consumerLoop(RpcExecutor.java:133) > at org.apache.hadoop.hbase.ipc.RpcExecutor$1.run(RpcExecutor.java:108) > at java.lang.Thread.run(Thread.java:748) > Caused by: java.lang.NullPointerException > at > org.apache.phoenix.expression.function.CollationKeyFunction.evaluate(CollationKeyFunction.java:121) > at > org.apache.phoenix.iterate.OrderedResultIterator.getResultIterator(OrderedResultIterator.java:260) > at > org.apache.phoenix.iterate.OrderedResultIterator.next(OrderedResultIterator.java:199) > at > org.apache.phoenix.iterate.NonAggregateRegionScannerFactory.getTopNScanner(NonAggregateRegionScannerFactory.java:322) > ... 11 more > at sqlline.IncrementalRows.hasNext(IncrementalRows.java:73) > at sqlline.TableOutputFormat.print(TableOutputFormat.java:33) > at sqlline.SqlLine.print(SqlLine.java:1652) > at sqlline.Commands.execute(Commands.java:833) > at sqlline.Commands.sql(Commands.java:732) > at sqlline.SqlLine.dispatch(SqlLine.java:807) > at sqlline.SqlLine.begin(SqlLine.java:681) > at sqlline.SqlLine.start(SqlLine.java:398) > at sqlline.SqlLine.main(SqlLine.java:292) > 0: jdbc:phoenix:localhost> select name from hello_table group by name order > by collation_key(name, 'en_US'); >
[jira] [Created] (PHOENIX-4650) Upgrade i18n-util dependency to version 1.0.4
Shehzaad Nakhoda created PHOENIX-4650: - Summary: Upgrade i18n-util dependency to version 1.0.4 Key: PHOENIX-4650 URL: https://issues.apache.org/jira/browse/PHOENIX-4650 Project: Phoenix Issue Type: Improvement Affects Versions: 4.14.0 Reporter: Shehzaad Nakhoda Assignee: Shehzaad Nakhoda Version 1.0.4 of i18n-util introduces ICU4J version 60.2 which has a number of improvements. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (PHOENIX-4624) COLLATION_KEY function cannot handle null values
[ https://issues.apache.org/jira/browse/PHOENIX-4624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16395702#comment-16395702 ] James Taylor commented on PHOENIX-4624: --- Yep, sorry about that - forgot to push it. It's been committed now. > COLLATION_KEY function cannot handle null values > > > Key: PHOENIX-4624 > URL: https://issues.apache.org/jira/browse/PHOENIX-4624 > Project: Phoenix > Issue Type: Bug >Reporter: Shehzaad Nakhoda >Assignee: Shehzaad Nakhoda >Priority: Major > Fix For: 4.14.0 > > Attachments: PHOENIX-4624_v1.patch > > > COLLATION_KEY throws a NullPointerException when it encounters values that > are null. > Example: > 0: jdbc:phoenix:localhost> create table hello_table (ID DECIMAL PRIMARY KEY, > NAME VARCHAR); > No rows affected (0.323 seconds) > 0: jdbc:phoenix:localhost> upsert into hello_table VALUES(1, 'One'); > 1 row affected (0.032 seconds) > 0: jdbc:phoenix:localhost> upsert into hello_table VALUES(2, 'Two'); > 1 row affected (0.006 seconds) > 0: jdbc:phoenix:localhost> upsert into hello_table VALUES(0, NULL); > 1 row affected (0.004 seconds) > 0: jdbc:phoenix:localhost> select * from hello_table order by > collation_key(name, 'en_US'); > +--+--+ > |ID| NAME > | > +--+--+ > java.lang.RuntimeException: org.apache.phoenix.exception.PhoenixIOException: > org.apache.phoenix.exception.PhoenixIOException: > org.apache.hadoop.hbase.DoNotRetryIOException: > HELLO_TABLE,,1519258211363.5898d1758d5b82ada5b27b2a8a9fba27.: null > at > org.apache.phoenix.util.ServerUtil.createIOException(ServerUtil.java:96) > at > org.apache.phoenix.util.ServerUtil.throwIOException(ServerUtil.java:62) > at > org.apache.phoenix.iterate.NonAggregateRegionScannerFactory.getTopNScanner(NonAggregateRegionScannerFactory.java:327) > at > org.apache.phoenix.iterate.NonAggregateRegionScannerFactory.getRegionScanner(NonAggregateRegionScannerFactory.java:164) > at > org.apache.phoenix.coprocessor.ScanRegionObserver.doPostScannerOpen(ScanRegionObserver.java:72) > at > org.apache.phoenix.coprocessor.BaseScannerRegionObserver$RegionScannerHolder.overrideDelegate(BaseScannerRegionObserver.java:235) > at > org.apache.phoenix.coprocessor.BaseScannerRegionObserver$RegionScannerHolder.nextRaw(BaseScannerRegionObserver.java:286) > at > org.apache.hadoop.hbase.regionserver.HRegionServer.scan(HRegionServer.java:3361) > at > org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:32492) > at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2211) > at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:104) > at > org.apache.hadoop.hbase.ipc.RpcExecutor.consumerLoop(RpcExecutor.java:133) > at org.apache.hadoop.hbase.ipc.RpcExecutor$1.run(RpcExecutor.java:108) > at java.lang.Thread.run(Thread.java:748) > Caused by: java.lang.NullPointerException > at > org.apache.phoenix.expression.function.CollationKeyFunction.evaluate(CollationKeyFunction.java:121) > at > org.apache.phoenix.iterate.OrderedResultIterator.getResultIterator(OrderedResultIterator.java:260) > at > org.apache.phoenix.iterate.OrderedResultIterator.next(OrderedResultIterator.java:199) > at > org.apache.phoenix.iterate.NonAggregateRegionScannerFactory.getTopNScanner(NonAggregateRegionScannerFactory.java:322) > ... 11 more > at sqlline.IncrementalRows.hasNext(IncrementalRows.java:73) > at sqlline.TableOutputFormat.print(TableOutputFormat.java:33) > at sqlline.SqlLine.print(SqlLine.java:1652) > at sqlline.Commands.execute(Commands.java:833) > at sqlline.Commands.sql(Commands.java:732) > at sqlline.SqlLine.dispatch(SqlLine.java:807) > at sqlline.SqlLine.begin(SqlLine.java:681) > at sqlline.SqlLine.start(SqlLine.java:398) > at sqlline.SqlLine.main(SqlLine.java:292) > 0: jdbc:phoenix:localhost> select name from hello_table group by name order > by collation_key(name, 'en_US'); > +--+ > | NAME | > +--+ > java.lang.NullPointerException > at > org.apache.phoenix.expression.function.CollationKeyFunction.evaluate(CollationKeyFunction.java:121) > at > org.apache.phoenix.iterate.OrderedResultIterator.getResultIterator(OrderedResultIterator.java:260) > at > org.apache.phoenix.iterate.OrderedResultIterator.next(OrderedResultIterator.java:199) >
[jira] [Commented] (PHOENIX-4624) COLLATION_KEY function cannot handle null values
[ https://issues.apache.org/jira/browse/PHOENIX-4624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16395684#comment-16395684 ] Thomas D'Silva commented on PHOENIX-4624: - [~jamestaylor] Should this be committed to the 4.x-HBase-0.98 branch as well? > COLLATION_KEY function cannot handle null values > > > Key: PHOENIX-4624 > URL: https://issues.apache.org/jira/browse/PHOENIX-4624 > Project: Phoenix > Issue Type: Bug >Reporter: Shehzaad Nakhoda >Assignee: Shehzaad Nakhoda >Priority: Major > Fix For: 4.14.0 > > Attachments: PHOENIX-4624_v1.patch > > > COLLATION_KEY throws a NullPointerException when it encounters values that > are null. > Example: > 0: jdbc:phoenix:localhost> create table hello_table (ID DECIMAL PRIMARY KEY, > NAME VARCHAR); > No rows affected (0.323 seconds) > 0: jdbc:phoenix:localhost> upsert into hello_table VALUES(1, 'One'); > 1 row affected (0.032 seconds) > 0: jdbc:phoenix:localhost> upsert into hello_table VALUES(2, 'Two'); > 1 row affected (0.006 seconds) > 0: jdbc:phoenix:localhost> upsert into hello_table VALUES(0, NULL); > 1 row affected (0.004 seconds) > 0: jdbc:phoenix:localhost> select * from hello_table order by > collation_key(name, 'en_US'); > +--+--+ > |ID| NAME > | > +--+--+ > java.lang.RuntimeException: org.apache.phoenix.exception.PhoenixIOException: > org.apache.phoenix.exception.PhoenixIOException: > org.apache.hadoop.hbase.DoNotRetryIOException: > HELLO_TABLE,,1519258211363.5898d1758d5b82ada5b27b2a8a9fba27.: null > at > org.apache.phoenix.util.ServerUtil.createIOException(ServerUtil.java:96) > at > org.apache.phoenix.util.ServerUtil.throwIOException(ServerUtil.java:62) > at > org.apache.phoenix.iterate.NonAggregateRegionScannerFactory.getTopNScanner(NonAggregateRegionScannerFactory.java:327) > at > org.apache.phoenix.iterate.NonAggregateRegionScannerFactory.getRegionScanner(NonAggregateRegionScannerFactory.java:164) > at > org.apache.phoenix.coprocessor.ScanRegionObserver.doPostScannerOpen(ScanRegionObserver.java:72) > at > org.apache.phoenix.coprocessor.BaseScannerRegionObserver$RegionScannerHolder.overrideDelegate(BaseScannerRegionObserver.java:235) > at > org.apache.phoenix.coprocessor.BaseScannerRegionObserver$RegionScannerHolder.nextRaw(BaseScannerRegionObserver.java:286) > at > org.apache.hadoop.hbase.regionserver.HRegionServer.scan(HRegionServer.java:3361) > at > org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:32492) > at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2211) > at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:104) > at > org.apache.hadoop.hbase.ipc.RpcExecutor.consumerLoop(RpcExecutor.java:133) > at org.apache.hadoop.hbase.ipc.RpcExecutor$1.run(RpcExecutor.java:108) > at java.lang.Thread.run(Thread.java:748) > Caused by: java.lang.NullPointerException > at > org.apache.phoenix.expression.function.CollationKeyFunction.evaluate(CollationKeyFunction.java:121) > at > org.apache.phoenix.iterate.OrderedResultIterator.getResultIterator(OrderedResultIterator.java:260) > at > org.apache.phoenix.iterate.OrderedResultIterator.next(OrderedResultIterator.java:199) > at > org.apache.phoenix.iterate.NonAggregateRegionScannerFactory.getTopNScanner(NonAggregateRegionScannerFactory.java:322) > ... 11 more > at sqlline.IncrementalRows.hasNext(IncrementalRows.java:73) > at sqlline.TableOutputFormat.print(TableOutputFormat.java:33) > at sqlline.SqlLine.print(SqlLine.java:1652) > at sqlline.Commands.execute(Commands.java:833) > at sqlline.Commands.sql(Commands.java:732) > at sqlline.SqlLine.dispatch(SqlLine.java:807) > at sqlline.SqlLine.begin(SqlLine.java:681) > at sqlline.SqlLine.start(SqlLine.java:398) > at sqlline.SqlLine.main(SqlLine.java:292) > 0: jdbc:phoenix:localhost> select name from hello_table group by name order > by collation_key(name, 'en_US'); > +--+ > | NAME | > +--+ > java.lang.NullPointerException > at > org.apache.phoenix.expression.function.CollationKeyFunction.evaluate(CollationKeyFunction.java:121) > at > org.apache.phoenix.iterate.OrderedResultIterator.getResultIterator(OrderedResultIterator.java:260) > at >
[jira] [Commented] (PHOENIX-3165) System table integrity check and repair tool
[ https://issues.apache.org/jira/browse/PHOENIX-3165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16395642#comment-16395642 ] Andrew Purtell commented on PHOENIX-3165: - We have a need for something that finds orphan rows in syscat and removes them. It could be an interesting occasion to start development of this tool. For the moment the orphan check and repair could be the first and only function. More to be added later. I vote for calling this tool "phck" It can be pronounced as "pee-haich-cee-kay" or ... some other way... per your personal preference. Maybe a bit on the nose but amusing nonetheless. > System table integrity check and repair tool > > > Key: PHOENIX-3165 > URL: https://issues.apache.org/jira/browse/PHOENIX-3165 > Project: Phoenix > Issue Type: New Feature >Reporter: Andrew Purtell >Priority: Critical > > When the Phoenix system tables become corrupt recovery is a painstaking > process of low level examination of table contents and manipulation of same > with the HBase shell. This is very difficult work providing no margin of > safety, and is a critical gap in terms of usability. > At the OS level, we have fsck. > At the HDFS level, we have fsck (integrity checking only, though) > At the HBase level, we have hbck. > At the Phoenix level, we lack a system table repair tool. > Implement a tool that: > - Does not depend on the Phoenix client. > - Supports integrity checking of SYSTEM tables. Check for the existence of > all required columns in entries. Check that entries exist for all Phoenix > managed tables (implies Phoenix should add supporting advisory-only metadata > to the HBase table schemas). Check that serializations are valid. > - Supports complete repair of SYSTEM.CATALOG and recreation, if necessary, of > other tables like SYSTEM.STATS which can be dropped to recover from an > emergency. We should be able to drop SYSTEM.CATALOG (or any other SYSTEM > table), run the tool, and have a completely correct recreation of > SYSTEM.CATALOG available at the end of its execution. > - To the extent we have or introduce cross-system-table invariants, check > them and offer a repair or reconstruction option. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (PHOENIX-3165) System table integrity check and repair tool
[ https://issues.apache.org/jira/browse/PHOENIX-3165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell reassigned PHOENIX-3165: --- Assignee: (was: Sergey Soldatov) > System table integrity check and repair tool > > > Key: PHOENIX-3165 > URL: https://issues.apache.org/jira/browse/PHOENIX-3165 > Project: Phoenix > Issue Type: New Feature >Reporter: Andrew Purtell >Priority: Critical > > When the Phoenix system tables become corrupt recovery is a painstaking > process of low level examination of table contents and manipulation of same > with the HBase shell. This is very difficult work providing no margin of > safety, and is a critical gap in terms of usability. > At the OS level, we have fsck. > At the HDFS level, we have fsck (integrity checking only, though) > At the HBase level, we have hbck. > At the Phoenix level, we lack a system table repair tool. > Implement a tool that: > - Does not depend on the Phoenix client. > - Supports integrity checking of SYSTEM tables. Check for the existence of > all required columns in entries. Check that entries exist for all Phoenix > managed tables (implies Phoenix should add supporting advisory-only metadata > to the HBase table schemas). Check that serializations are valid. > - Supports complete repair of SYSTEM.CATALOG and recreation, if necessary, of > other tables like SYSTEM.STATS which can be dropped to recover from an > emergency. We should be able to drop SYSTEM.CATALOG (or any other SYSTEM > table), run the tool, and have a completely correct recreation of > SYSTEM.CATALOG available at the end of its execution. > - To the extent we have or introduce cross-system-table invariants, check > them and offer a repair or reconstruction option. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (PHOENIX-4432) PHOENIX-672 (Grant/Revoke) documentation
[ https://issues.apache.org/jira/browse/PHOENIX-4432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karan Mehta resolved PHOENIX-4432. -- Resolution: Fixed Doc committed upstream. Checkout Grant: [https://phoenix.apache.org/language/index.html#grant] Revoke: [https://phoenix.apache.org/language/index.html#revoke] > PHOENIX-672 (Grant/Revoke) documentation > > > Key: PHOENIX-4432 > URL: https://issues.apache.org/jira/browse/PHOENIX-4432 > Project: Phoenix > Issue Type: Bug >Reporter: Karan Mehta >Assignee: Karan Mehta >Priority: Major > Labels: documentation > Attachments: GrantRevoke.png, PHOENIX-4432.001.patch, > PHOENIX-4432.002.patch > > > Now that PHOENIX-672 is in and users can GRANT/REVOKE permissions on users, > tables and namespaces, we should document this feature and add it to our > grammar syntax on the website, so that users can start using it. > This JIRA is for tracking that effort. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (PHOENIX-4432) PHOENIX-672 (Grant/Revoke) documentation
[ https://issues.apache.org/jira/browse/PHOENIX-4432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16395572#comment-16395572 ] Karan Mehta commented on PHOENIX-4432: -- Added the updated patch. [~tdsilva] Please review. > PHOENIX-672 (Grant/Revoke) documentation > > > Key: PHOENIX-4432 > URL: https://issues.apache.org/jira/browse/PHOENIX-4432 > Project: Phoenix > Issue Type: Bug >Reporter: Karan Mehta >Assignee: Karan Mehta >Priority: Major > Labels: documentation > Attachments: GrantRevoke.png, PHOENIX-4432.001.patch, > PHOENIX-4432.002.patch > > > Now that PHOENIX-672 is in and users can GRANT/REVOKE permissions on users, > tables and namespaces, we should document this feature and add it to our > grammar syntax on the website, so that users can start using it. > This JIRA is for tracking that effort. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (PHOENIX-4432) PHOENIX-672 (Grant/Revoke) documentation
[ https://issues.apache.org/jira/browse/PHOENIX-4432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16395568#comment-16395568 ] Thomas D'Silva commented on PHOENIX-4432: - +1 LGTM > PHOENIX-672 (Grant/Revoke) documentation > > > Key: PHOENIX-4432 > URL: https://issues.apache.org/jira/browse/PHOENIX-4432 > Project: Phoenix > Issue Type: Bug >Reporter: Karan Mehta >Assignee: Karan Mehta >Priority: Major > Labels: documentation > Attachments: GrantRevoke.png, PHOENIX-4432.001.patch, > PHOENIX-4432.002.patch > > > Now that PHOENIX-672 is in and users can GRANT/REVOKE permissions on users, > tables and namespaces, we should document this feature and add it to our > grammar syntax on the website, so that users can start using it. > This JIRA is for tracking that effort. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-4432) PHOENIX-672 (Grant/Revoke) documentation
[ https://issues.apache.org/jira/browse/PHOENIX-4432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karan Mehta updated PHOENIX-4432: - Summary: PHOENIX-672 (Grant/Revoke) documentation (was: PHOENIX-672 documentation) > PHOENIX-672 (Grant/Revoke) documentation > > > Key: PHOENIX-4432 > URL: https://issues.apache.org/jira/browse/PHOENIX-4432 > Project: Phoenix > Issue Type: Bug >Reporter: Karan Mehta >Assignee: Karan Mehta >Priority: Major > Labels: documentation > Attachments: GrantRevoke.png, PHOENIX-4432.001.patch, > PHOENIX-4432.002.patch > > > Now that PHOENIX-672 is in and users can GRANT/REVOKE permissions on users, > tables and namespaces, we should document this feature and add it to our > grammar syntax on the website, so that users can start using it. > This JIRA is for tracking that effort. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-4432) PHOENIX-672 documentation
[ https://issues.apache.org/jira/browse/PHOENIX-4432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karan Mehta updated PHOENIX-4432: - Attachment: PHOENIX-4432.002.patch > PHOENIX-672 documentation > - > > Key: PHOENIX-4432 > URL: https://issues.apache.org/jira/browse/PHOENIX-4432 > Project: Phoenix > Issue Type: Bug >Reporter: Karan Mehta >Assignee: Karan Mehta >Priority: Major > Labels: documentation > Attachments: GrantRevoke.png, PHOENIX-4432.001.patch, > PHOENIX-4432.002.patch > > > Now that PHOENIX-672 is in and users can GRANT/REVOKE permissions on users, > tables and namespaces, we should document this feature and add it to our > grammar syntax on the website, so that users can start using it. > This JIRA is for tracking that effort. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (PHOENIX-4641) Perform index maintenance on server-side for transactional local indexes
[ https://issues.apache.org/jira/browse/PHOENIX-4641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16395424#comment-16395424 ] Ohad Shacham commented on PHOENIX-4641: --- FYI [~jamestaylor]. I created OMID-93, will create a pull request tomorrow. > Perform index maintenance on server-side for transactional local indexes > > > Key: PHOENIX-4641 > URL: https://issues.apache.org/jira/browse/PHOENIX-4641 > Project: Phoenix > Issue Type: Bug >Reporter: James Taylor >Priority: Major > > PHOENIX-4278 changed index maintenance for transactional tables to be > performed on the client side. For local indexes, this is not ideal and not > really necessary as the updates to the indexes will all be local. By doing > this on the client side, we'd incur extra overhead: > - extra RPCs for updates to local index tables separate from RPCs for data > tables > - related to this, more network bandwidth would be used > - calculation on client-side to determine region start key (which is someone > unclear whether there's a race condition with a split occurring while this is > being determined) > - the updates to local indexes would no longer be row-level atomic with data > table HBase updates (though they'd be atomic because they're transactional) > With Tephra, we can do the index maintenance on the server side without > further changes. For Omid, it's more difficult since we must: > - perform all writes > - write to the commit table > - write the shadow cells (which requires knowing the index updates) > If there will already be an API to write the shadow cells (required for the > initial population of local indexes), then perhaps we could piggyback on > that. On the client-side, we could do the following: > - perform all writes > - write to the commit table > - perform writes again, but with a flag set to indicate that only the shadow > cells need to be written (note we already have the > mutation.setAttribute(REPLAY_WRITES, REPLAY_ONLY_INDEX_WRITES) option that > will help with this) . In this case, we'd execute the logic to compute the > index updates twice, but on the plus side, we wouldn't incur the other > overhead mentioned before. > All in all, it's unclear if this is worth doing. It doesn't make a lot of > sense to use local indexes for transactional tables, since one of the biggest > benefits of local indexes is row level atomicity between index and table rows > is already achieved more generally by transactions. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (PHOENIX-4643) Implement ARRAY_REMOVE built in function
[
https://issues.apache.org/jira/browse/PHOENIX-4643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16395401#comment-16395401
]
ASF GitHub Bot commented on PHOENIX-4643:
-
Github user xjodoin commented on a diff in the pull request:
https://github.com/apache/phoenix/pull/294#discussion_r173839154
--- Diff:
phoenix-core/src/main/java/org/apache/phoenix/expression/function/ArrayRemoveFunction.java
---
@@ -0,0 +1,79 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.phoenix.expression.function;
+
+import java.util.List;
+
+import org.apache.hadoop.hbase.io.ImmutableBytesWritable;
+import org.apache.phoenix.expression.Expression;
+import org.apache.phoenix.parse.FunctionParseNode;
+import org.apache.phoenix.schema.SortOrder;
+import org.apache.phoenix.schema.TypeMismatchException;
+import org.apache.phoenix.schema.types.PArrayDataTypeDecoder;
+import org.apache.phoenix.schema.types.PArrayDataTypeEncoder;
+import org.apache.phoenix.schema.types.PBinaryArray;
+import org.apache.phoenix.schema.types.PDataType;
+import org.apache.phoenix.schema.types.PVarbinary;
+import org.apache.phoenix.schema.types.PVarbinaryArray;
+
+@FunctionParseNode.BuiltInFunction(name = ArrayRemoveFunction.NAME, args =
{
+ @FunctionParseNode.Argument(allowedTypes = {
PBinaryArray.class, PVarbinaryArray.class }),
+ @FunctionParseNode.Argument(allowedTypes = { PVarbinary.class
}, defaultValue = "null") })
+public class ArrayRemoveFunction extends ArrayModifierFunction {
+
+ public static final String NAME = "ARRAY_REMOVE";
+
+ public ArrayRemoveFunction() {
+ }
+
+ public ArrayRemoveFunction(List children) throws
TypeMismatchException {
+ super(children);
+ }
+
+ @Override
+ protected boolean modifierFunction(ImmutableBytesWritable ptr, int
length, int offset, byte[] arrayBytes,
+ PDataType baseType, int arrayLength, Integer maxLength,
Expression arrayExp) {
+ SortOrder sortOrder = arrayExp.getSortOrder();
+
+ if (ptr.getLength() == 0 || arrayBytes.length == 0) {
+ ptr.set(arrayBytes, offset, length);
+ return true;
+ }
+
+ PArrayDataTypeEncoder arrayDataTypeEncoder = new
PArrayDataTypeEncoder(baseType, sortOrder);
+
+ for (int arrayIndex = 0; arrayIndex < arrayLength;
arrayIndex++) {
+ ImmutableBytesWritable ptr2 = new
ImmutableBytesWritable(arrayBytes, offset, length);
+ PArrayDataTypeDecoder.positionAtArrayElement(ptr2,
arrayIndex, baseType, maxLength);
+ if (baseType.compareTo(ptr2, sortOrder, ptr, sortOrder,
baseType) != 0) {
--- End diff --
it's works I added some tests to validate it
> Implement ARRAY_REMOVE built in function
> -
>
> Key: PHOENIX-4643
> URL: https://issues.apache.org/jira/browse/PHOENIX-4643
> Project: Phoenix
> Issue Type: New Feature
>Reporter: Xavier Jodoin
>Priority: Minor
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] phoenix pull request #294: PHOENIX-4643 Implement ARRAY_REMOVE built in func...
Github user xjodoin commented on a diff in the pull request:
https://github.com/apache/phoenix/pull/294#discussion_r173839154
--- Diff:
phoenix-core/src/main/java/org/apache/phoenix/expression/function/ArrayRemoveFunction.java
---
@@ -0,0 +1,79 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.phoenix.expression.function;
+
+import java.util.List;
+
+import org.apache.hadoop.hbase.io.ImmutableBytesWritable;
+import org.apache.phoenix.expression.Expression;
+import org.apache.phoenix.parse.FunctionParseNode;
+import org.apache.phoenix.schema.SortOrder;
+import org.apache.phoenix.schema.TypeMismatchException;
+import org.apache.phoenix.schema.types.PArrayDataTypeDecoder;
+import org.apache.phoenix.schema.types.PArrayDataTypeEncoder;
+import org.apache.phoenix.schema.types.PBinaryArray;
+import org.apache.phoenix.schema.types.PDataType;
+import org.apache.phoenix.schema.types.PVarbinary;
+import org.apache.phoenix.schema.types.PVarbinaryArray;
+
+@FunctionParseNode.BuiltInFunction(name = ArrayRemoveFunction.NAME, args =
{
+ @FunctionParseNode.Argument(allowedTypes = {
PBinaryArray.class, PVarbinaryArray.class }),
+ @FunctionParseNode.Argument(allowedTypes = { PVarbinary.class
}, defaultValue = "null") })
+public class ArrayRemoveFunction extends ArrayModifierFunction {
+
+ public static final String NAME = "ARRAY_REMOVE";
+
+ public ArrayRemoveFunction() {
+ }
+
+ public ArrayRemoveFunction(List children) throws
TypeMismatchException {
+ super(children);
+ }
+
+ @Override
+ protected boolean modifierFunction(ImmutableBytesWritable ptr, int
length, int offset, byte[] arrayBytes,
+ PDataType baseType, int arrayLength, Integer maxLength,
Expression arrayExp) {
+ SortOrder sortOrder = arrayExp.getSortOrder();
+
+ if (ptr.getLength() == 0 || arrayBytes.length == 0) {
+ ptr.set(arrayBytes, offset, length);
+ return true;
+ }
+
+ PArrayDataTypeEncoder arrayDataTypeEncoder = new
PArrayDataTypeEncoder(baseType, sortOrder);
+
+ for (int arrayIndex = 0; arrayIndex < arrayLength;
arrayIndex++) {
+ ImmutableBytesWritable ptr2 = new
ImmutableBytesWritable(arrayBytes, offset, length);
+ PArrayDataTypeDecoder.positionAtArrayElement(ptr2,
arrayIndex, baseType, maxLength);
+ if (baseType.compareTo(ptr2, sortOrder, ptr, sortOrder,
baseType) != 0) {
--- End diff --
it's works I added some tests to validate it
---
[jira] [Updated] (PHOENIX-4629) date/datetime/timestamp with timezone issue
[
https://issues.apache.org/jira/browse/PHOENIX-4629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jepson updated PHOENIX-4629:
Summary: date/datetime/timestamp with timezone issue (was: timestamp with
timezone issue)
> date/datetime/timestamp with timezone issue
> ---
>
> Key: PHOENIX-4629
> URL: https://issues.apache.org/jira/browse/PHOENIX-4629
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.10.0
> Environment: phoenix4.10-hbase1.2
>Reporter: Jepson
>Priority: Major
> Labels: patch
> Fix For: 4.10.0
>
> Attachments: Phoenix-4629-v2.patch, Phoenix-4629.patch
>
> Original Estimate: 96h
> Remaining Estimate: 96h
>
> *1.Create timezonetest table:*
> {code:java}
> CREATE TABLE JYDW.timezonetest (
> id bigint(11) not null primary key,
> date_c date ,
> datetime_c timestamp ,
> timestamp_c timestamp
> )SALT_BUCKETS = 12, COMPRESSION='SNAPPY';{code}
> *2.Create TimestampTest.java*
> {code:java}
> package org.apache.phoenix.jdbc;
> import org.apache.phoenix.query.BaseConnectionlessQueryTest;
> import org.apache.phoenix.query.QueryServices;
> import java.sql.Connection;
> import java.sql.DriverManager;
> import java.sql.ResultSet;
> import java.util.Properties;
> /**
> * Created by Jepson on 2017/11/2.
> *
> CREATE TABLE JYDW.timezonetest (
> id bigint(11) not null primary key,
> date_c date ,
> datetime_c timestamp ,
> timestamp_c timestamp
> )SALT_BUCKETS = 12, COMPRESSION='SNAPPY';
> */
> public class TimestampTest extends BaseConnectionlessQueryTest {
> public static void main(String[] args) throws Exception {
> Properties props = new Properties();
>// props.setProperty(QueryServices.DATE_FORMAT_TIMEZONE_ATTRIB,
> "Asia/Shanghai");
> String url =
> "jdbc:phoenix:192.168.117.137,192.168.117.138,192.168.117.140,192.168.117.141,192.168.117.142:2181:/hbase";
> //Connection conn = DriverManager.getConnection(url,props);
> Connection conn = DriverManager.getConnection(url);
> conn.createStatement().execute("UPSERT INTO
> jydw.TIMEZONETEST(id,date_c,datetime_c,timestamp_c) \n" +
> "values(101,'2018-02-25','2018-02-25 00:00:00','2018-02-25
> 10:00:00')");
> conn.commit();
> ResultSet rs = conn.createStatement().executeQuery("SELECT * FROM
> TIMEZONETEST");
> while(rs.next()) {
> System.out.println(rs.getString("id")+" : " +
> rs.getString("date_c")+" : " + rs.getString("datetime_c")+" : " +
> rs.getString("timestamp_c"));
> }
> rs.close();
> conn.close();
> }
> }
> {code}
> *3.Run the TimestampTest.java,the console print message:*
> *id : date_c : datetime_c : timestamp_c*
> 101 : 2018-02-24 16:00:00.000 : 2018-02-24 16:00:00.000 : 2018-02-25
> 02:00:00.000
> 100 : 2018-02-24 16:00:00.000 : 2018-02-24 16:00:00.000 : 2018-02-25
> 02:00:00.000
> *{color:#ff}minus 8 hours, is also wrong.{color}*
> *4.Reference these, not work*
> https://issues.apache.org/jira/browse/PHOENIX-997
> https://issues.apache.org/jira/browse/PHOENIX-1485
> 5.Modify DateUtil.java
> {code:java}
> public static final String DEFAULT_TIME_ZONE_ID = "GMT";
> public static final String LOCAL_TIME_ZONE_ID = "LOCAL";{code}
> *Changed:*
> {code:java}
> public static final String DEFAULT_TIME_ZONE_ID = "Asia/Shanghai";
> public static final String LOCAL_TIME_ZONE_ID = "Asia/Shanghai";
> {code}
> -
> {code:java}
> private final DateTimeFormatter formatter =
> ISO_DATE_TIME_FORMATTER.withZone(DateTimeZone.forID("UTC"));{code}
> *Changed:*
> {code:java}
> private final DateTimeFormatter formatter =
> ISO_DATE_TIME_FORMATTER.withZone(DateTimeZone.forID("Asia/Shanghai"));
> {code}
>
> 6.Again run *TimestampTest.java, the result is ok.*
> *id : date_c : datetime_c : timestamp_c*
> 101 : 2018-02-25 00:00:00.000 : 2018-02-25 00:00:00.000 : 2018-02-25
> 10:00:00.000
> 100 : 2018-02-25 00:00:00.000 : 2018-02-25 00:00:00.000 : 2018-02-25
> 10:00:00.000
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (PHOENIX-4629) timestamp with timezone issue
[
https://issues.apache.org/jira/browse/PHOENIX-4629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16395049#comment-16395049
]
Jepson commented on PHOENIX-4629:
-
*1.Phoenix-4629.patch:*
Change the timezone value to "Asia/Shanghai" , is a fixed value.
*2.Phoenix-4629-v2.patch:*
2.1.Phoenix select sql with timezone : using the parameter
"phoenix.query.dateFormatTimeZone";
2.2.Phoenix upsert sql with timezone : the code with
"DateTimeZone.getDefault()", value is from system time zone;
Centos6/7:
[root@hadoop38 ~]# ll /etc/localtime
lrwxrwxrwx 1 root root 33 May 25 2017 /etc/localtime ->
/usr/share/zoneinfo/Asia/Shanghai
[root@hadoop38 ~]#
> timestamp with timezone issue
> -
>
> Key: PHOENIX-4629
> URL: https://issues.apache.org/jira/browse/PHOENIX-4629
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.10.0
> Environment: phoenix4.10-hbase1.2
>Reporter: Jepson
>Priority: Major
> Attachments: Phoenix-4629-v2.patch, Phoenix-4629.patch
>
> Original Estimate: 96h
> Remaining Estimate: 96h
>
> *1.Create timezonetest table:*
> {code:java}
> CREATE TABLE JYDW.timezonetest (
> id bigint(11) not null primary key,
> date_c date ,
> datetime_c timestamp ,
> timestamp_c timestamp
> )SALT_BUCKETS = 12, COMPRESSION='SNAPPY';{code}
> *2.Create TimestampTest.java*
> {code:java}
> package org.apache.phoenix.jdbc;
> import org.apache.phoenix.query.BaseConnectionlessQueryTest;
> import org.apache.phoenix.query.QueryServices;
> import java.sql.Connection;
> import java.sql.DriverManager;
> import java.sql.ResultSet;
> import java.util.Properties;
> /**
> * Created by Jepson on 2017/11/2.
> *
> CREATE TABLE JYDW.timezonetest (
> id bigint(11) not null primary key,
> date_c date ,
> datetime_c timestamp ,
> timestamp_c timestamp
> )SALT_BUCKETS = 12, COMPRESSION='SNAPPY';
> */
> public class TimestampTest extends BaseConnectionlessQueryTest {
> public static void main(String[] args) throws Exception {
> Properties props = new Properties();
>// props.setProperty(QueryServices.DATE_FORMAT_TIMEZONE_ATTRIB,
> "Asia/Shanghai");
> String url =
> "jdbc:phoenix:192.168.117.137,192.168.117.138,192.168.117.140,192.168.117.141,192.168.117.142:2181:/hbase";
> //Connection conn = DriverManager.getConnection(url,props);
> Connection conn = DriverManager.getConnection(url);
> conn.createStatement().execute("UPSERT INTO
> jydw.TIMEZONETEST(id,date_c,datetime_c,timestamp_c) \n" +
> "values(101,'2018-02-25','2018-02-25 00:00:00','2018-02-25
> 10:00:00')");
> conn.commit();
> ResultSet rs = conn.createStatement().executeQuery("SELECT * FROM
> TIMEZONETEST");
> while(rs.next()) {
> System.out.println(rs.getString("id")+" : " +
> rs.getString("date_c")+" : " + rs.getString("datetime_c")+" : " +
> rs.getString("timestamp_c"));
> }
> rs.close();
> conn.close();
> }
> }
> {code}
> *3.Run the TimestampTest.java,the console print message:*
> *id : date_c : datetime_c : timestamp_c*
> 101 : 2018-02-24 16:00:00.000 : 2018-02-24 16:00:00.000 : 2018-02-25
> 02:00:00.000
> 100 : 2018-02-24 16:00:00.000 : 2018-02-24 16:00:00.000 : 2018-02-25
> 02:00:00.000
> *{color:#ff}minus 8 hours, is also wrong.{color}*
> *4.Reference these, not work*
> https://issues.apache.org/jira/browse/PHOENIX-997
> https://issues.apache.org/jira/browse/PHOENIX-1485
> 5.Modify DateUtil.java
> {code:java}
> public static final String DEFAULT_TIME_ZONE_ID = "GMT";
> public static final String LOCAL_TIME_ZONE_ID = "LOCAL";{code}
> *Changed:*
> {code:java}
> public static final String DEFAULT_TIME_ZONE_ID = "Asia/Shanghai";
> public static final String LOCAL_TIME_ZONE_ID = "Asia/Shanghai";
> {code}
> -
> {code:java}
> private final DateTimeFormatter formatter =
> ISO_DATE_TIME_FORMATTER.withZone(DateTimeZone.forID("UTC"));{code}
> *Changed:*
> {code:java}
> private final DateTimeFormatter formatter =
> ISO_DATE_TIME_FORMATTER.withZone(DateTimeZone.forID("Asia/Shanghai"));
> {code}
>
> 6.Again run *TimestampTest.java, the result is ok.*
> *id : date_c : datetime_c : timestamp_c*
> 101 : 2018-02-25 00:00:00.000 : 2018-02-25 00:00:00.000 : 2018-02-25
> 10:00:00.000
> 100 : 2018-02-25 00:00:00.000 : 2018-02-25 00:00:00.000 : 2018-02-25
> 10:00:00.000
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (PHOENIX-4629) timestamp with timezone issue
[
https://issues.apache.org/jira/browse/PHOENIX-4629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jepson updated PHOENIX-4629:
Attachment: Phoenix-4629-v2.patch
> timestamp with timezone issue
> -
>
> Key: PHOENIX-4629
> URL: https://issues.apache.org/jira/browse/PHOENIX-4629
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.10.0
> Environment: phoenix4.10-hbase1.2
>Reporter: Jepson
>Priority: Major
> Attachments: Phoenix-4629-v2.patch, Phoenix-4629.patch
>
> Original Estimate: 96h
> Remaining Estimate: 96h
>
> *1.Create timezonetest table:*
> {code:java}
> CREATE TABLE JYDW.timezonetest (
> id bigint(11) not null primary key,
> date_c date ,
> datetime_c timestamp ,
> timestamp_c timestamp
> )SALT_BUCKETS = 12, COMPRESSION='SNAPPY';{code}
> *2.Create TimestampTest.java*
> {code:java}
> package org.apache.phoenix.jdbc;
> import org.apache.phoenix.query.BaseConnectionlessQueryTest;
> import org.apache.phoenix.query.QueryServices;
> import java.sql.Connection;
> import java.sql.DriverManager;
> import java.sql.ResultSet;
> import java.util.Properties;
> /**
> * Created by Jepson on 2017/11/2.
> *
> CREATE TABLE JYDW.timezonetest (
> id bigint(11) not null primary key,
> date_c date ,
> datetime_c timestamp ,
> timestamp_c timestamp
> )SALT_BUCKETS = 12, COMPRESSION='SNAPPY';
> */
> public class TimestampTest extends BaseConnectionlessQueryTest {
> public static void main(String[] args) throws Exception {
> Properties props = new Properties();
>// props.setProperty(QueryServices.DATE_FORMAT_TIMEZONE_ATTRIB,
> "Asia/Shanghai");
> String url =
> "jdbc:phoenix:192.168.117.137,192.168.117.138,192.168.117.140,192.168.117.141,192.168.117.142:2181:/hbase";
> //Connection conn = DriverManager.getConnection(url,props);
> Connection conn = DriverManager.getConnection(url);
> conn.createStatement().execute("UPSERT INTO
> jydw.TIMEZONETEST(id,date_c,datetime_c,timestamp_c) \n" +
> "values(101,'2018-02-25','2018-02-25 00:00:00','2018-02-25
> 10:00:00')");
> conn.commit();
> ResultSet rs = conn.createStatement().executeQuery("SELECT * FROM
> TIMEZONETEST");
> while(rs.next()) {
> System.out.println(rs.getString("id")+" : " +
> rs.getString("date_c")+" : " + rs.getString("datetime_c")+" : " +
> rs.getString("timestamp_c"));
> }
> rs.close();
> conn.close();
> }
> }
> {code}
> *3.Run the TimestampTest.java,the console print message:*
> *id : date_c : datetime_c : timestamp_c*
> 101 : 2018-02-24 16:00:00.000 : 2018-02-24 16:00:00.000 : 2018-02-25
> 02:00:00.000
> 100 : 2018-02-24 16:00:00.000 : 2018-02-24 16:00:00.000 : 2018-02-25
> 02:00:00.000
> *{color:#ff}minus 8 hours, is also wrong.{color}*
> *4.Reference these, not work*
> https://issues.apache.org/jira/browse/PHOENIX-997
> https://issues.apache.org/jira/browse/PHOENIX-1485
> 5.Modify DateUtil.java
> {code:java}
> public static final String DEFAULT_TIME_ZONE_ID = "GMT";
> public static final String LOCAL_TIME_ZONE_ID = "LOCAL";{code}
> *Changed:*
> {code:java}
> public static final String DEFAULT_TIME_ZONE_ID = "Asia/Shanghai";
> public static final String LOCAL_TIME_ZONE_ID = "Asia/Shanghai";
> {code}
> -
> {code:java}
> private final DateTimeFormatter formatter =
> ISO_DATE_TIME_FORMATTER.withZone(DateTimeZone.forID("UTC"));{code}
> *Changed:*
> {code:java}
> private final DateTimeFormatter formatter =
> ISO_DATE_TIME_FORMATTER.withZone(DateTimeZone.forID("Asia/Shanghai"));
> {code}
>
> 6.Again run *TimestampTest.java, the result is ok.*
> *id : date_c : datetime_c : timestamp_c*
> 101 : 2018-02-25 00:00:00.000 : 2018-02-25 00:00:00.000 : 2018-02-25
> 10:00:00.000
> 100 : 2018-02-25 00:00:00.000 : 2018-02-25 00:00:00.000 : 2018-02-25
> 10:00:00.000
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
