[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] [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-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=16394059#comment-16394059 ] Shehzaad Nakhoda commented on PHOENIX-4418: --- [~tdsilva] I've rebased the patch (PHOENIX-4418_v3.patch) - in case _v2.patch doesn't work. thanks > UPPER() and LOWER() functions should be locale-aware > > > Key: PHOENIX-4418 > URL: https://issues.apache.org/jira/browse/PHOENIX-4418 > Project: Phoenix > Issue Type: Improvement >Affects Versions: 4.13.0 >Reporter: Shehzaad Nakhoda >Assignee: Shehzaad Nakhoda >Priority: Major > Fix For: 4.14.0 > > Attachments: PHOENIX-4418_v1.patch, PHOENIX-4418_v2.patch, > PHOENIX-4418_v3.patch, upper_lower_locale_doc.patch > > > Correct conversion of a string to upper or lower case depends on Locale. > Java's upper case and lower case conversion routines allow passing in a > locale. > It should be possible to pass in a locale to UPPER() and LOWER() in Phoenix > so that locale-specific case conversion can be supported in Phoenix. > See java.lang.String#toUpperCase() -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-4418) UPPER() and LOWER() functions should be locale-aware
[ https://issues.apache.org/jira/browse/PHOENIX-4418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shehzaad Nakhoda updated PHOENIX-4418: -- Attachment: PHOENIX-4418_v3.patch > UPPER() and LOWER() functions should be locale-aware > > > Key: PHOENIX-4418 > URL: https://issues.apache.org/jira/browse/PHOENIX-4418 > Project: Phoenix > Issue Type: Improvement >Affects Versions: 4.13.0 >Reporter: Shehzaad Nakhoda >Assignee: Shehzaad Nakhoda >Priority: Major > Fix For: 4.14.0 > > Attachments: PHOENIX-4418_v1.patch, PHOENIX-4418_v2.patch, > PHOENIX-4418_v3.patch, upper_lower_locale_doc.patch > > > Correct conversion of a string to upper or lower case depends on Locale. > Java's upper case and lower case conversion routines allow passing in a > locale. > It should be possible to pass in a locale to UPPER() and LOWER() in Phoenix > so that locale-specific case conversion can be supported in Phoenix. > See java.lang.String#toUpperCase() -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-4647) Column header doesn't handle optional arguments correctly
[ https://issues.apache.org/jira/browse/PHOENIX-4647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shehzaad Nakhoda updated PHOENIX-4647: -- Description: SUBSTR(NAME, 1) being rendered as SUBSTR(NAME, 1, ) in things like column headings. For example: 0: jdbc:phoenix:> create table hello_table (ID DECIMAL PRIMARY KEY, NAME VARCHAR); No rows affected (1.252 seconds) 0: jdbc:phoenix:> upsert into hello_table values(1, 'abc'); 1 row affected (0.025 seconds) 0: jdbc:phoenix:> select substr(name, 1) from hello_table; ++ | SUBSTR(NAME, 1, ) | ++ | abc| ++ Looks to me like there's a bug - SUBSTR(NAME, 1) should be represented as SUBSTR(NAME, 1) not as SUBSTR(NAME, 1, ) was: SUBSTR(NAME, 1) being rendered as SUBSTR(NAME, 1, 1) in things like column headings. For example: 0: jdbc:phoenix:> create table hello_table (ID DECIMAL PRIMARY KEY, NAME VARCHAR); No rows affected (1.252 seconds) 0: jdbc:phoenix:> upsert into hello_table values(1, 'abc'); 1 row affected (0.025 seconds) 0: jdbc:phoenix:> select substr(name, 1) from hello_table; ++ | SUBSTR(NAME, 1, ) | ++ | abc| ++ Looks to me like there's a bug - SUBSTR(NAME, 1) should be represented as SUBSTR(NAME, 1) not as SUBSTR(NAME, 1, ) > Column header doesn't handle optional arguments correctly > - > > Key: PHOENIX-4647 > URL: https://issues.apache.org/jira/browse/PHOENIX-4647 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.14.0 >Reporter: Shehzaad Nakhoda >Priority: Major > > SUBSTR(NAME, 1) > being rendered as > SUBSTR(NAME, 1, ) > in things like column headings. > For example: > 0: jdbc:phoenix:> create table hello_table (ID DECIMAL PRIMARY KEY, NAME > VARCHAR); > No rows affected (1.252 seconds) > 0: jdbc:phoenix:> upsert into hello_table values(1, 'abc'); > 1 row affected (0.025 seconds) > 0: jdbc:phoenix:> select substr(name, 1) from hello_table; > ++ > | SUBSTR(NAME, 1, ) | > ++ > | abc| > ++ > Looks to me like there's a bug - > SUBSTR(NAME, 1) should be represented as SUBSTR(NAME, 1) not as SUBSTR(NAME, > 1, ) -- 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=16392673#comment-16392673 ] Shehzaad Nakhoda commented on PHOENIX-4418: --- [~tdsilva] thanks. I've attached a patch file for the doc changes (on top of https://svn.apache.org/repos/asf/phoenix) > 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, > upper_lower_locale_doc.patch > > > Correct conversion of a string to upper or lower case depends on Locale. > Java's upper case and lower case conversion routines allow passing in a > locale. > It should be possible to pass in a locale to UPPER() and LOWER() in Phoenix > so that locale-specific case conversion can be supported in Phoenix. > See java.lang.String#toUpperCase() -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-4418) UPPER() and LOWER() functions should be locale-aware
[ https://issues.apache.org/jira/browse/PHOENIX-4418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shehzaad Nakhoda updated PHOENIX-4418: -- Attachment: upper_lower_locale_doc.patch > 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, > 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-4647) Column header doesn't handle optional arguments correctly
[ https://issues.apache.org/jira/browse/PHOENIX-4647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16392580#comment-16392580 ] Shehzaad Nakhoda commented on PHOENIX-4647: --- [~jamestaylor] - the jira you requested. > Column header doesn't handle optional arguments correctly > - > > Key: PHOENIX-4647 > URL: https://issues.apache.org/jira/browse/PHOENIX-4647 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.14.0 >Reporter: Shehzaad Nakhoda >Priority: Major > > SUBSTR(NAME, 1) > being rendered as > SUBSTR(NAME, 1, 1) > in things like column headings. > For example: > 0: jdbc:phoenix:> create table hello_table (ID DECIMAL PRIMARY KEY, NAME > VARCHAR); > No rows affected (1.252 seconds) > 0: jdbc:phoenix:> upsert into hello_table values(1, 'abc'); > 1 row affected (0.025 seconds) > 0: jdbc:phoenix:> select substr(name, 1) from hello_table; > ++ > | SUBSTR(NAME, 1, ) | > ++ > | abc| > ++ > Looks to me like there's a bug - > SUBSTR(NAME, 1) should be represented as SUBSTR(NAME, 1) not as SUBSTR(NAME, > 1, ) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (PHOENIX-4647) Column header doesn't handle optional arguments correctly
Shehzaad Nakhoda created PHOENIX-4647: - Summary: Column header doesn't handle optional arguments correctly Key: PHOENIX-4647 URL: https://issues.apache.org/jira/browse/PHOENIX-4647 Project: Phoenix Issue Type: Bug Affects Versions: 4.14.0 Reporter: Shehzaad Nakhoda SUBSTR(NAME, 1) being rendered as SUBSTR(NAME, 1, 1) in things like column headings. For example: 0: jdbc:phoenix:> create table hello_table (ID DECIMAL PRIMARY KEY, NAME VARCHAR); No rows affected (1.252 seconds) 0: jdbc:phoenix:> upsert into hello_table values(1, 'abc'); 1 row affected (0.025 seconds) 0: jdbc:phoenix:> select substr(name, 1) from hello_table; ++ | SUBSTR(NAME, 1, ) | ++ | abc| ++ Looks to me like there's a bug - SUBSTR(NAME, 1) should be represented as SUBSTR(NAME, 1) not as SUBSTR(NAME, 1, ) -- 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=16386984#comment-16386984 ] Shehzaad Nakhoda commented on PHOENIX-4624: --- Thanks [~jamestaylor]!(y) > 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) > at >
[jira] [Updated] (PHOENIX-4624) COLLATION_KEY function cannot handle null values
[ https://issues.apache.org/jira/browse/PHOENIX-4624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shehzaad Nakhoda updated PHOENIX-4624: -- Attachment: PHOENIX-4624_v1.patch > 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) > at >
[jira] [Comment Edited] (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=16385783#comment-16385783 ] Shehzaad Nakhoda edited comment on PHOENIX-4418 at 3/5/18 8:33 AM: --- [~tdsilva] here is another patch. It skirts around my question above by explicitly adding a second argument to calls to UPPER() was (Author: shehzaadn): [~tdsilva] here is another patch, that skirts around my question above by explicitly adding a second argument to calls to UPPER() > 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 > > > 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-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=16385783#comment-16385783 ] Shehzaad Nakhoda commented on PHOENIX-4418: --- [~tdsilva] here is another patch, that skirts around my question above by explicitly adding a second argument to calls to UPPER() > 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 > > > Correct conversion of a string to upper or lower case depends on Locale. > Java's upper case and lower case conversion routines allow passing in a > locale. > It should be possible to pass in a locale to UPPER() and LOWER() in Phoenix > so that locale-specific case conversion can be supported in Phoenix. > See java.lang.String#toUpperCase() -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-4418) UPPER() and LOWER() functions should be locale-aware
[ https://issues.apache.org/jira/browse/PHOENIX-4418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shehzaad Nakhoda updated PHOENIX-4418: -- Attachment: PHOENIX-4418_v2.patch > 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 > > > 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-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=16385683#comment-16385683
]
Shehzaad Nakhoda commented on PHOENIX-4418:
---
Hi [~tdsilva]
A lot of these failures are being caused by the expression
UPPER(NAME)
being rendered as
UPPER(NAME, )
in things like column headings.
For example:
{{0: jdbc:phoenix:> create table hello_table (ID DECIMAL PRIMARY KEY, NAME
VARCHAR);
No rows affected (2.252 seconds)
0: jdbc:phoenix:> upsert into hello_table values(1, 'abc');
1 row affected (0.03 seconds)
0: jdbc:phoenix:> select upper(name) from hello_table;
++
| UPPER(NAME, ) |
++
| ABC|
++
0: jdbc:phoenix:> select substr(name, 1) from hello_table;
++
| SUBSTR(NAME, 1, ) |
++
| abc|
++
}}
I tried this with other functions that have optional parameters like SUBSTR and
saw the same effect.
And this is trickling into EXPLAIN plan as well.
Looks to me like there's a bug -
SUBSTR(NAME, 1) should be represented as SUBSTR(NAME, 1) not as SUBSTR(NAME, 1,
)
Given this, should I update the assert in the tests?
> 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
>
>
> 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] [Assigned] (PHOENIX-4624) COLLATION_KEY function cannot handle null values
[ https://issues.apache.org/jira/browse/PHOENIX-4624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shehzaad Nakhoda reassigned PHOENIX-4624: - Assignee: Shehzaad Nakhoda > 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 > > 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) > at > org.apache.phoenix.iterate.OrderedAggregatingResultIterator.next(OrderedAggregatingResultIterator.java:51) > at >
[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=16376320#comment-16376320 ] Shehzaad Nakhoda commented on PHOENIX-4418: --- Hello Phoenix committers, Can this be committed? Thanks! [~jamestaylor] [~mujtabachohan] [~vincentpoon] [~karanmehta93] [~aertoria] [~tdsilva] > 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 > > > 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] [Created] (PHOENIX-4624) COLLATION_KEY function cannot handle null values
Shehzaad Nakhoda created PHOENIX-4624: - Summary: 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 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) at org.apache.phoenix.iterate.OrderedAggregatingResultIterator.next(OrderedAggregatingResultIterator.java:51) at org.apache.phoenix.jdbc.PhoenixResultSet.next(PhoenixResultSet.java:779) at sqlline.IncrementalRows.hasNext(IncrementalRows.java:62) 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)
[jira] [Issue Comment Deleted] (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:all-tabpanel ] Shehzaad Nakhoda updated PHOENIX-4418: -- Comment: was deleted (was: [~jamestaylor] a patch for your perusal.) > 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 > > > Correct conversion of a string to upper or lower case depends on Locale. > Java's upper case and lower case conversion routines allow passing in a > locale. > It should be possible to pass in a locale to UPPER() and LOWER() in Phoenix > so that locale-specific case conversion can be supported in Phoenix. > See java.lang.String#toUpperCase() -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-4418) UPPER() and LOWER() functions should be locale-aware
[ https://issues.apache.org/jira/browse/PHOENIX-4418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shehzaad Nakhoda updated PHOENIX-4418: -- Attachment: PHOENIX-4418_v1.patch > 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 > > > 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] [Assigned] (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:all-tabpanel ] Shehzaad Nakhoda reassigned PHOENIX-4418: - Assignee: Shehzaad Nakhoda Fix Version/s: 4.14.0 > 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 > > > 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-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=16346556#comment-16346556 ] Shehzaad Nakhoda commented on PHOENIX-4418: --- [~jamestaylor] a patch for your perusal. > 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 > > > 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] [Created] (PHOENIX-4418) UPPER() and LOWER() functions should be locale-aware
Shehzaad Nakhoda created PHOENIX-4418: - Summary: 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 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 (v6.4.14#64029)
[jira] [Updated] (PHOENIX-4384) Phoenix server jar doesn't include icu4j jars
[ https://issues.apache.org/jira/browse/PHOENIX-4384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shehzaad Nakhoda updated PHOENIX-4384: -- Attachment: PHOENIX-4384_v1.patch > Phoenix server jar doesn't include icu4j jars > - > > Key: PHOENIX-4384 > URL: https://issues.apache.org/jira/browse/PHOENIX-4384 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.13.0 >Reporter: Shehzaad Nakhoda >Assignee: Shehzaad Nakhoda > Fix For: 4.13.0 > > Attachments: PHOENIX-4384_v1.patch > > > The phoenix server "shaded" jar is supposed to include all? its dependencies. > However icu4j is missing. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (PHOENIX-4384) Phoenix server jar doesn't include icu4j jars
Shehzaad Nakhoda created PHOENIX-4384: - Summary: Phoenix server jar doesn't include icu4j jars Key: PHOENIX-4384 URL: https://issues.apache.org/jira/browse/PHOENIX-4384 Project: Phoenix Issue Type: Bug Affects Versions: 4.13.0 Reporter: Shehzaad Nakhoda Assignee: Shehzaad Nakhoda The phoenix server "shaded" jar is supposed to include all? its dependencies. However icu4j is missing. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (PHOENIX-4367) Document new COLLATION_KEY function
[ https://issues.apache.org/jira/browse/PHOENIX-4367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shehzaad Nakhoda updated PHOENIX-4367: -- Attachment: collation_key_doc.patch > Document new COLLATION_KEY function > --- > > Key: PHOENIX-4367 > URL: https://issues.apache.org/jira/browse/PHOENIX-4367 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.13.0 >Reporter: James Taylor >Assignee: Shehzaad Nakhoda >Priority: Minor > Fix For: 4.13.0 > > Attachments: collation_key_doc.patch > > > Please add a small entry to phoenix.csv (which lives in > https://svn.apache.org/repos/asf/phoenix) to describe how to use the new > COLLATION_KEY built-in function. You can copy/paste an existing function > description and see examples here: > https://phoenix.apache.org/language/functions.html. For directions on > updating the website, see here: > https://phoenix.apache.org/language/functions.html -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Issue Comment Deleted] (PHOENIX-4237) Allow sorting on (Java) collation keys for non-English locales
[ https://issues.apache.org/jira/browse/PHOENIX-4237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shehzaad Nakhoda updated PHOENIX-4237: -- Comment: was deleted (was: A new patch that removes external code and uses maven dependencies to bring in external files.) > Allow sorting on (Java) collation keys for non-English locales > -- > > Key: PHOENIX-4237 > URL: https://issues.apache.org/jira/browse/PHOENIX-4237 > Project: Phoenix > Issue Type: Improvement >Reporter: Shehzaad Nakhoda >Assignee: Shehzaad Nakhoda >Priority: Major > Fix For: 4.12.0 > > Attachments: PHOENIX-4237_v1.patch, PHOENIX-4237_v2.patch, > PHOENIX-4237_v3.patch > > > Strings stored via Phoenix can be composed from a subset of the entire set of > Unicode characters. The natural sort order for strings for different > languages often differs from the order dictated by the binary representation > of the characters of these strings. Java provides the idea of a Collator > which given an input string and a (language) locale can generate a Collation > Key which can then be used to compare strings in that natural order. > Salesforce has recently open-sourced grammaticus. IBM has open-sourced ICU4J > some time ago. These technologies can be combined to provide a robust new > Phoenix function that can be used in an ORDER BY clause to sort strings > according to the user's locale. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (PHOENIX-4237) Allow sorting on (Java) collation keys for non-English locales
[ https://issues.apache.org/jira/browse/PHOENIX-4237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shehzaad Nakhoda updated PHOENIX-4237: -- Attachment: PHOENIX-4237_v3.patch A new patch that removes the external com.salesforce and com.ibm code files in favor of maven dependencies. > Allow sorting on (Java) collation keys for non-English locales > -- > > Key: PHOENIX-4237 > URL: https://issues.apache.org/jira/browse/PHOENIX-4237 > Project: Phoenix > Issue Type: Improvement >Reporter: Shehzaad Nakhoda >Assignee: Shehzaad Nakhoda >Priority: Major > Fix For: 4.12.0 > > Attachments: PHOENIX-4237_v1.patch, PHOENIX-4237_v2.patch, > PHOENIX-4237_v3.patch > > > Strings stored via Phoenix can be composed from a subset of the entire set of > Unicode characters. The natural sort order for strings for different > languages often differs from the order dictated by the binary representation > of the characters of these strings. Java provides the idea of a Collator > which given an input string and a (language) locale can generate a Collation > Key which can then be used to compare strings in that natural order. > Salesforce has recently open-sourced grammaticus. IBM has open-sourced ICU4J > some time ago. These technologies can be combined to provide a robust new > Phoenix function that can be used in an ORDER BY clause to sort strings > according to the user's locale. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (PHOENIX-4237) Allow sorting on (Java) collation keys for non-English locales
[ https://issues.apache.org/jira/browse/PHOENIX-4237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shehzaad Nakhoda updated PHOENIX-4237: -- Attachment: PHOENIX-4237.patch_v3 A new patch that removes external code and uses maven dependencies to bring in external files. > Allow sorting on (Java) collation keys for non-English locales > -- > > Key: PHOENIX-4237 > URL: https://issues.apache.org/jira/browse/PHOENIX-4237 > Project: Phoenix > Issue Type: Improvement >Reporter: Shehzaad Nakhoda >Assignee: Shehzaad Nakhoda >Priority: Major > Fix For: 4.12.0 > > Attachments: PHOENIX-4237_v1.patch, PHOENIX-4237_v2.patch > > > Strings stored via Phoenix can be composed from a subset of the entire set of > Unicode characters. The natural sort order for strings for different > languages often differs from the order dictated by the binary representation > of the characters of these strings. Java provides the idea of a Collator > which given an input string and a (language) locale can generate a Collation > Key which can then be used to compare strings in that natural order. > Salesforce has recently open-sourced grammaticus. IBM has open-sourced ICU4J > some time ago. These technologies can be combined to provide a robust new > Phoenix function that can be used in an ORDER BY clause to sort strings > according to the user's locale. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (PHOENIX-4237) Allow sorting on (Java) collation keys for non-English locales
[ https://issues.apache.org/jira/browse/PHOENIX-4237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shehzaad Nakhoda updated PHOENIX-4237: -- Attachment: (was: PHOENIX-4237.patch_v3) > Allow sorting on (Java) collation keys for non-English locales > -- > > Key: PHOENIX-4237 > URL: https://issues.apache.org/jira/browse/PHOENIX-4237 > Project: Phoenix > Issue Type: Improvement >Reporter: Shehzaad Nakhoda >Assignee: Shehzaad Nakhoda >Priority: Major > Fix For: 4.12.0 > > Attachments: PHOENIX-4237_v1.patch, PHOENIX-4237_v2.patch > > > Strings stored via Phoenix can be composed from a subset of the entire set of > Unicode characters. The natural sort order for strings for different > languages often differs from the order dictated by the binary representation > of the characters of these strings. Java provides the idea of a Collator > which given an input string and a (language) locale can generate a Collation > Key which can then be used to compare strings in that natural order. > Salesforce has recently open-sourced grammaticus. IBM has open-sourced ICU4J > some time ago. These technologies can be combined to provide a robust new > Phoenix function that can be used in an ORDER BY clause to sort strings > according to the user's locale. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PHOENIX-4331) Missing version tag for apache-rat-plugin in pom.xml files
[ https://issues.apache.org/jira/browse/PHOENIX-4331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16227044#comment-16227044 ] Shehzaad Nakhoda commented on PHOENIX-4331: --- [~elserj] you are right. For our internal build we do change the parent in the phoenix pom. So we should probably address this in our internal build. Thanks for taking a look. [~mujtabachohan] fyi > Missing version tag for apache-rat-plugin in pom.xml files > -- > > Key: PHOENIX-4331 > URL: https://issues.apache.org/jira/browse/PHOENIX-4331 > Project: Phoenix > Issue Type: Bug >Reporter: Shehzaad Nakhoda > Attachments: PHOENIX-4331_v1.patch > > > Some internal build processes require maven plugins (under > build->plugins->plugin) to have version numbers. apache-rat-plugin is used in > a number of pom.xml's under phoenix but it doesn't have a version number > specified. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (PHOENIX-4331) Missing version tag for apache-rat-plugin in pom.xml
[ https://issues.apache.org/jira/browse/PHOENIX-4331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16224477#comment-16224477 ] Shehzaad Nakhoda edited comment on PHOENIX-4331 at 10/30/17 7:57 AM: - [^PHOENIX-4331_v1.patch] is a patch that declares 0.12 as the apache-rat-plugin version was (Author: shehzaadn): Here is a patch that declares 0.12 as the apache-rat-plugin version > Missing version tag for apache-rat-plugin in pom.xml > > > Key: PHOENIX-4331 > URL: https://issues.apache.org/jira/browse/PHOENIX-4331 > Project: Phoenix > Issue Type: Bug >Reporter: Shehzaad Nakhoda > Attachments: PHOENIX-4331_v1.patch > > > Some internal build processes require maven plugins (under > build->plugins->plugin) to have version numbers. apache-rat-plugin is used in > a number of pom.xml's under phoenix but it doesn't have a version number > specified. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (PHOENIX-4331) Missing version tag for apache-rat-plugin in pom.xml files
[ https://issues.apache.org/jira/browse/PHOENIX-4331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shehzaad Nakhoda updated PHOENIX-4331: -- Summary: Missing version tag for apache-rat-plugin in pom.xml files (was: Missing version tag for apache-rat-plugin in pom.xml) > Missing version tag for apache-rat-plugin in pom.xml files > -- > > Key: PHOENIX-4331 > URL: https://issues.apache.org/jira/browse/PHOENIX-4331 > Project: Phoenix > Issue Type: Bug >Reporter: Shehzaad Nakhoda > Attachments: PHOENIX-4331_v1.patch > > > Some internal build processes require maven plugins (under > build->plugins->plugin) to have version numbers. apache-rat-plugin is used in > a number of pom.xml's under phoenix but it doesn't have a version number > specified. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (PHOENIX-4331) Missing version tag for apache-rat-plugin in pom.xml
[ https://issues.apache.org/jira/browse/PHOENIX-4331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shehzaad Nakhoda updated PHOENIX-4331: -- Attachment: PHOENIX-4331_v1.patch > Missing version tag for apache-rat-plugin in pom.xml > > > Key: PHOENIX-4331 > URL: https://issues.apache.org/jira/browse/PHOENIX-4331 > Project: Phoenix > Issue Type: Bug >Reporter: Shehzaad Nakhoda > Attachments: PHOENIX-4331_v1.patch > > > Some internal build processes require maven plugins (under > build->plugins->plugin) to have version numbers. apache-rat-plugin is used in > a number of pom.xml's under phoenix but it doesn't have a version number > specified. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (PHOENIX-4331) Missing version tag for apache-rat-plugin in pom.xml
Shehzaad Nakhoda created PHOENIX-4331: - Summary: Missing version tag for apache-rat-plugin in pom.xml Key: PHOENIX-4331 URL: https://issues.apache.org/jira/browse/PHOENIX-4331 Project: Phoenix Issue Type: Bug Reporter: Shehzaad Nakhoda Some internal build processes require maven plugins (under build->plugins->plugin) to have version numbers. apache-rat-plugin is used in a number of pom.xml's under phoenix but it doesn't have a version number specified. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PHOENIX-3945) Introduce new Scalar Function to calculate a collation key from a string
[ https://issues.apache.org/jira/browse/PHOENIX-3945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16219740#comment-16219740 ] Shehzaad Nakhoda commented on PHOENIX-3945: --- Duplicate of PHOENIX-4237 > Introduce new Scalar Function to calculate a collation key from a string > > > Key: PHOENIX-3945 > URL: https://issues.apache.org/jira/browse/PHOENIX-3945 > Project: Phoenix > Issue Type: New Feature >Reporter: Shehzaad Nakhoda > > It is necessary to do sort varchars in a language-sensitive way. > A scalar function is needed which given a string and a locale should return a > byte array that can then be sorted in binary order. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (PHOENIX-3945) Introduce new Scalar Function to calculate a collation key from a string
[ https://issues.apache.org/jira/browse/PHOENIX-3945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shehzaad Nakhoda resolved PHOENIX-3945. --- Resolution: Duplicate > Introduce new Scalar Function to calculate a collation key from a string > > > Key: PHOENIX-3945 > URL: https://issues.apache.org/jira/browse/PHOENIX-3945 > Project: Phoenix > Issue Type: New Feature >Reporter: Shehzaad Nakhoda > > It is necessary to do sort varchars in a language-sensitive way. > A scalar function is needed which given a string and a locale should return a > byte array that can then be sorted in binary order. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (PHOENIX-4237) Allow sorting on (Java) collation keys for non-English locales
[ https://issues.apache.org/jira/browse/PHOENIX-4237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shehzaad Nakhoda updated PHOENIX-4237: -- Attachment: PHOENIX-4237_v2.patch This patch fixes the test failure caused by an JDK 7-incompatible jar from grammaticus by removing the dependency and bringing in LocaleUtils (the only class we need from grammaticus) as source code. > Allow sorting on (Java) collation keys for non-English locales > -- > > Key: PHOENIX-4237 > URL: https://issues.apache.org/jira/browse/PHOENIX-4237 > Project: Phoenix > Issue Type: Improvement >Reporter: Shehzaad Nakhoda >Assignee: Shehzaad Nakhoda > Fix For: 4.12.0 > > Attachments: PHOENIX-4237_v1.patch, PHOENIX-4237_v2.patch > > > Strings stored via Phoenix can be composed from a subset of the entire set of > Unicode characters. The natural sort order for strings for different > languages often differs from the order dictated by the binary representation > of the characters of these strings. Java provides the idea of a Collator > which given an input string and a (language) locale can generate a Collation > Key which can then be used to compare strings in that natural order. > Salesforce has recently open-sourced grammaticus. IBM has open-sourced ICU4J > some time ago. These technologies can be combined to provide a robust new > Phoenix function that can be used in an ORDER BY clause to sort strings > according to the user's locale. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (PHOENIX-4237) Allow sorting on (Java) collation keys for non-English locales
[ https://issues.apache.org/jira/browse/PHOENIX-4237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shehzaad Nakhoda updated PHOENIX-4237: -- Fix Version/s: 4.12.0 > Allow sorting on (Java) collation keys for non-English locales > -- > > Key: PHOENIX-4237 > URL: https://issues.apache.org/jira/browse/PHOENIX-4237 > Project: Phoenix > Issue Type: Improvement >Reporter: Shehzaad Nakhoda > Fix For: 4.12.0 > > > Strings stored via Phoenix can be composed from a subset of the entire set of > Unicode characters. The natural sort order for strings for different > languages often differs from the order dictated by the binary representation > of the characters of these strings. Java provides the idea of a Collator > which given an input string and a (language) locale can generate a Collation > Key which can then be used to compare strings in that natural order. > Salesforce has recently open-sourced grammaticus. IBM has open-sourced ICU4J > some time ago. These technologies can be combined to provide a robust new > Phoenix function that can be used in an ORDER BY clause to sort strings > according to the user's locale. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (PHOENIX-4237) Allow sorting on (Java) collation keys for non-English locales
[ https://issues.apache.org/jira/browse/PHOENIX-4237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shehzaad Nakhoda updated PHOENIX-4237: -- Description: Strings stored via Phoenix can be composed from a subset of the entire set of Unicode characters. The natural sort order for strings for different languages often differs from the order dictated by the binary representation of the characters of these strings. Java provides the idea of a Collator which given an input string and a (language) locale can generate a Collation Key which can then be used to compare strings in that natural order. Salesforce has recently open-sourced grammaticus. IBM has open-sourced ICU4J some time ago. These technologies can be combined to provide a robust new Phoenix function that can be used in an ORDER BY clause to sort strings according to the user's locale. was: Strings stored via Phoenix can be from the entire set of Unicode characters. The natural sort order for strings for different languages often differs from the order dictated by the binary representation of the characters of these strings. Java provides the idea of a Collator which given an input string and a (language) locale can generate a Collation Key which can then be used to compare strings in that natural order. Salesforce has recently open-sourced grammaticus. IBM has open-sourced ICU4J some time ago. These technologies can be combined to provide a robust new Phoenix function that can be used in an ORDER BY clause to sort strings according to the user's locale. > Allow sorting on (Java) collation keys for non-English locales > -- > > Key: PHOENIX-4237 > URL: https://issues.apache.org/jira/browse/PHOENIX-4237 > Project: Phoenix > Issue Type: Improvement >Reporter: Shehzaad Nakhoda > > Strings stored via Phoenix can be composed from a subset of the entire set of > Unicode characters. The natural sort order for strings for different > languages often differs from the order dictated by the binary representation > of the characters of these strings. Java provides the idea of a Collator > which given an input string and a (language) locale can generate a Collation > Key which can then be used to compare strings in that natural order. > Salesforce has recently open-sourced grammaticus. IBM has open-sourced ICU4J > some time ago. These technologies can be combined to provide a robust new > Phoenix function that can be used in an ORDER BY clause to sort strings > according to the user's locale. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (PHOENIX-4237) Allow sorting on (Java) collation keys for non-English locales
[ https://issues.apache.org/jira/browse/PHOENIX-4237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shehzaad Nakhoda updated PHOENIX-4237: -- Description: Strings stored via Phoenix can be from the entire set of Unicode characters. The natural sort order for strings for different languages often differs from the order dictated by the binary representation of the characters of these strings. Java provides the idea of a Collator which given an input string and a (language) locale can generate a Collation Key which can then be used to compare strings in that natural order. Salesforce has recently open-sourced grammaticus. IBM has open-sourced ICU4J some time ago. These technologies can be combined to provide a robust new Phoenix function that can be used in an ORDER BY clause to sort strings according to the user's locale. > Allow sorting on (Java) collation keys for non-English locales > -- > > Key: PHOENIX-4237 > URL: https://issues.apache.org/jira/browse/PHOENIX-4237 > Project: Phoenix > Issue Type: Improvement >Reporter: Shehzaad Nakhoda > > Strings stored via Phoenix can be from the entire set of Unicode characters. > The natural sort order for strings for different languages often differs from > the order dictated by the binary representation of the characters of these > strings. Java provides the idea of a Collator which given an input string and > a (language) locale can generate a Collation Key which can then be used to > compare strings in that natural order. > Salesforce has recently open-sourced grammaticus. IBM has open-sourced ICU4J > some time ago. These technologies can be combined to provide a robust new > Phoenix function that can be used in an ORDER BY clause to sort strings > according to the user's locale. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (PHOENIX-4237) Allow sorting on (Java) collation keys for non-English locales
Shehzaad Nakhoda created PHOENIX-4237: - Summary: Allow sorting on (Java) collation keys for non-English locales Key: PHOENIX-4237 URL: https://issues.apache.org/jira/browse/PHOENIX-4237 Project: Phoenix Issue Type: Improvement Reporter: Shehzaad Nakhoda -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PHOENIX-3945) Introduce new Scalar Function to calculate a collation key from a string
[ https://issues.apache.org/jira/browse/PHOENIX-3945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16050515#comment-16050515 ] Shehzaad Nakhoda commented on PHOENIX-3945: --- [~jamestaylor] Here's the JIRA we discussed. > Introduce new Scalar Function to calculate a collation key from a string > > > Key: PHOENIX-3945 > URL: https://issues.apache.org/jira/browse/PHOENIX-3945 > Project: Phoenix > Issue Type: New Feature >Reporter: Shehzaad Nakhoda > > It is necessary to do sort varchars in a language-sensitive way. > A scalar function is needed which given a string and a locale should return a > byte array that can then be sorted in binary order. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (PHOENIX-3945) Introduce new Scalar Function to calculate a collation key from a string
Shehzaad Nakhoda created PHOENIX-3945: - Summary: Introduce new Scalar Function to calculate a collation key from a string Key: PHOENIX-3945 URL: https://issues.apache.org/jira/browse/PHOENIX-3945 Project: Phoenix Issue Type: New Feature Reporter: Shehzaad Nakhoda It is necessary to do sort varchars in a language-sensitive way. A scalar function is needed which given a string and a locale should return a byte array that can then be sorted in binary order. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PHOENIX-3934) VARBINARY type doesn't have a useful representation in sqlline.py
[
https://issues.apache.org/jira/browse/PHOENIX-3934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16046093#comment-16046093
]
Shehzaad Nakhoda commented on PHOENIX-3934:
---
Thanks [~julianhyde].
[~jamestaylor] I took a look at PhoenixResultSet and PhoenixConnection and I
see that formatters are set up for some types but not for PVarBinary. Seems to
me that if we can figure out a good format for byte arrays, PhoenixConnection
is the place to add it.
> VARBINARY type doesn't have a useful representation in sqlline.py
> -
>
> Key: PHOENIX-3934
> URL: https://issues.apache.org/jira/browse/PHOENIX-3934
> Project: Phoenix
> Issue Type: Bug
>Reporter: Shehzaad Nakhoda
>
> When interacting with a commonly-used command line client like sqlline.py a
> VARBINARY type is not represented in a useful way in query results. The value
> seems to be a representation of the Java hashcode for the byte array, which
> changes with every query.
> The following transcript will make this obvious. Note the value of MYBYTES is
> hard to make use of and moreover it changes with every query. I would like to
> see some stable representation of the byte array itself.
> 0: jdbc:phoenix:localhost:2181:/hbase> create table my_table (name VARCHAR
> PRIMARY KEY, mybytes VARBINARY);
> No rows affected (2.33 seconds)
> 0: jdbc:phoenix:localhost:2181:/hbase> upsert into my_table(name, mybytes)
> values('hello', '12312');
> 1 row affected (0.004 seconds)
> 0: jdbc:phoenix:localhost:2181:/hbase> select * from my_table;
> ++-+
> | NAME | MYBYTES |
> ++-+
> | hello | [B@650eab8 |
> ++-+
> 1 row selected (0.017 seconds)
> 0: jdbc:phoenix:localhost:2181:/hbase> select * from my_table;
> ++--+
> | NAME | MYBYTES|
> ++--+
> | hello | [B@53f48368 |
> ++--+
> 1 row selected (0.015 seconds)
> 0: jdbc:phoenix:localhost:2181:/hbase> select * from my_table;
> ++--+
> | NAME | MYBYTES|
> ++--+
> | hello | [B@71b3bc45 |
> ++--+
> 1 row selected (0.015 seconds)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (PHOENIX-3934) VARBINARY type doesn't have a useful representation in sqlline.py
[
https://issues.apache.org/jira/browse/PHOENIX-3934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16045888#comment-16045888
]
Shehzaad Nakhoda commented on PHOENIX-3934:
---
Thanks [~jamestaylor].
I filed https://github.com/julianhyde/sqlline/issues/64
CC: [~julianhyde]
> VARBINARY type doesn't have a useful representation in sqlline.py
> -
>
> Key: PHOENIX-3934
> URL: https://issues.apache.org/jira/browse/PHOENIX-3934
> Project: Phoenix
> Issue Type: Bug
>Reporter: Shehzaad Nakhoda
>
> When interacting with a commonly-used command line client like sqlline.py a
> VARBINARY type is not represented in a useful way in query results. The value
> seems to be a representation of the Java hashcode for the byte array, which
> changes with every query.
> The following transcript will make this obvious. Note the value of MYBYTES is
> hard to make use of and moreover it changes with every query. I would like to
> see some stable representation of the byte array itself.
> 0: jdbc:phoenix:localhost:2181:/hbase> create table my_table (name VARCHAR
> PRIMARY KEY, mybytes VARBINARY);
> No rows affected (2.33 seconds)
> 0: jdbc:phoenix:localhost:2181:/hbase> upsert into my_table(name, mybytes)
> values('hello', '12312');
> 1 row affected (0.004 seconds)
> 0: jdbc:phoenix:localhost:2181:/hbase> select * from my_table;
> ++-+
> | NAME | MYBYTES |
> ++-+
> | hello | [B@650eab8 |
> ++-+
> 1 row selected (0.017 seconds)
> 0: jdbc:phoenix:localhost:2181:/hbase> select * from my_table;
> ++--+
> | NAME | MYBYTES|
> ++--+
> | hello | [B@53f48368 |
> ++--+
> 1 row selected (0.015 seconds)
> 0: jdbc:phoenix:localhost:2181:/hbase> select * from my_table;
> ++--+
> | NAME | MYBYTES|
> ++--+
> | hello | [B@71b3bc45 |
> ++--+
> 1 row selected (0.015 seconds)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (PHOENIX-3934) VARBINARY type doesn't have a useful representation in sqlline.py
[
https://issues.apache.org/jira/browse/PHOENIX-3934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shehzaad Nakhoda updated PHOENIX-3934:
--
Description:
When interacting with a commonly-used command line client like sqlline.py a
VARBINARY type is not represented in a useful way in query results. The value
seems to be a representation of the Java hashcode for the byte array, which
changes with every query.
The following transcript will make this obvious. Note the value of MYBYTES is
hard to make use of and moreover it changes with every query. I would like to
see some stable representation of the byte array itself.
0: jdbc:phoenix:localhost:2181:/hbase> create table my_table (name VARCHAR
PRIMARY KEY, mybytes VARBINARY);
No rows affected (2.33 seconds)
0: jdbc:phoenix:localhost:2181:/hbase> upsert into my_table(name, mybytes)
values('hello', '12312');
1 row affected (0.004 seconds)
0: jdbc:phoenix:localhost:2181:/hbase> select * from my_table;
++-+
| NAME | MYBYTES |
++-+
| hello | [B@650eab8 |
++-+
1 row selected (0.017 seconds)
0: jdbc:phoenix:localhost:2181:/hbase> select * from my_table;
++--+
| NAME | MYBYTES|
++--+
| hello | [B@53f48368 |
++--+
1 row selected (0.015 seconds)
0: jdbc:phoenix:localhost:2181:/hbase> select * from my_table;
++--+
| NAME | MYBYTES|
++--+
| hello | [B@71b3bc45 |
++--+
1 row selected (0.015 seconds)
> VARBINARY type doesn't have a useful representation in sqlline.py
> -
>
> Key: PHOENIX-3934
> URL: https://issues.apache.org/jira/browse/PHOENIX-3934
> Project: Phoenix
> Issue Type: Bug
>Reporter: Shehzaad Nakhoda
>
> When interacting with a commonly-used command line client like sqlline.py a
> VARBINARY type is not represented in a useful way in query results. The value
> seems to be a representation of the Java hashcode for the byte array, which
> changes with every query.
> The following transcript will make this obvious. Note the value of MYBYTES is
> hard to make use of and moreover it changes with every query. I would like to
> see some stable representation of the byte array itself.
> 0: jdbc:phoenix:localhost:2181:/hbase> create table my_table (name VARCHAR
> PRIMARY KEY, mybytes VARBINARY);
> No rows affected (2.33 seconds)
> 0: jdbc:phoenix:localhost:2181:/hbase> upsert into my_table(name, mybytes)
> values('hello', '12312');
> 1 row affected (0.004 seconds)
> 0: jdbc:phoenix:localhost:2181:/hbase> select * from my_table;
> ++-+
> | NAME | MYBYTES |
> ++-+
> | hello | [B@650eab8 |
> ++-+
> 1 row selected (0.017 seconds)
> 0: jdbc:phoenix:localhost:2181:/hbase> select * from my_table;
> ++--+
> | NAME | MYBYTES|
> ++--+
> | hello | [B@53f48368 |
> ++--+
> 1 row selected (0.015 seconds)
> 0: jdbc:phoenix:localhost:2181:/hbase> select * from my_table;
> ++--+
> | NAME | MYBYTES|
> ++--+
> | hello | [B@71b3bc45 |
> ++--+
> 1 row selected (0.015 seconds)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (PHOENIX-3934) VARBINARY type doesn't have a useful representation in sqlline.py
Shehzaad Nakhoda created PHOENIX-3934: - Summary: VARBINARY type doesn't have a useful representation in sqlline.py Key: PHOENIX-3934 URL: https://issues.apache.org/jira/browse/PHOENIX-3934 Project: Phoenix Issue Type: Bug Reporter: Shehzaad Nakhoda -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (PHOENIX-3219) RuntimeExceptions should be caught and thrown as SQLException
[ 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-3210) Exception trying to cast Double to BigDecimal in UpsertCompiler
[ 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] [Created] (PHOENIX-3219) RuntimeExceptions should be caught and thrown as SQLException
Shehzaad Nakhoda created PHOENIX-3219: - Summary: 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-3210) Exception trying to cast Double to BigDecimal in UpsertCompiler
[ https://issues.apache.org/jira/browse/PHOENIX-3210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15447299#comment-15447299 ] Shehzaad Nakhoda commented on PHOENIX-3210: --- I was trying to go through UpsertCompiler (and related code) to see what kind of literal value in an upsert statement would be parsed as a Double, but I wasn't successful at first try. > 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 > > > 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
[
https://issues.apache.org/jira/browse/PHOENIX-3210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15447293#comment-15447293
]
Shehzaad Nakhoda commented on PHOENIX-3210:
---
It's actually a view over a table that has just a couple of columns.
The columns in the view are:
("OPPORTUNITY_NAME" VARCHAR, "o.ID" VARCHAR, "TYPE" VARCHAR, "LEAD_SOURCE"
VARCHAR, "AMOUNT" DECIMAL, "o.ISOCODE" VARCHAR, "EXP_AMOUNT" DECIMAL,
"CLOSE_DATE" DATE, "NEXT_STEP" VARCHAR, "STAGE_NAME" VARCHAR, "PROBABILITY"
DECIMAL, "FISCAL_QUARTER" VARCHAR, "AGE" DECIMAL, "AGE.ID" VARCHAR,
"CREATED_DATE" TIME, "FULL_NAME" VARCHAR, "u.ID" VARCHAR, "ROLLUP_DESCRIPTION"
VARCHAR, "ACCOUNT_NAME" VARCHAR, "a.ID" VARCHAR, "OWNER_ID" VARCHAR)
Unfortunately I still don't have the actual upsert statement that fails.
> 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
>
>
> 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
[ https://issues.apache.org/jira/browse/PHOENIX-3210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15446815#comment-15446815 ] Shehzaad Nakhoda commented on PHOENIX-3210: --- [~prakul] any update? > 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 > > > 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
[ https://issues.apache.org/jira/browse/PHOENIX-3210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15437855#comment-15437855 ] Shehzaad Nakhoda commented on PHOENIX-3210: --- [~prakul] once you have an upsert statement where this can be reproduced, please let me know. That will help me plan any workaround. Thanks! > 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 > > > 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] [Created] (PHOENIX-3210) Exception trying to cast Double to BigDecimal in UpsertCompiler
Shehzaad Nakhoda created PHOENIX-3210: - Summary: 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 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-541) Make mutable batch size bytes-based instead of row-based
[ https://issues.apache.org/jira/browse/PHOENIX-541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14542984#comment-14542984 ] Shehzaad Nakhoda commented on PHOENIX-541: -- This should be accompanied by a call to be able to check how much room is still available, before doing an UPSERT VALUES, or some kind of soft exception so that the caller can commit. Make mutable batch size bytes-based instead of row-based Key: PHOENIX-541 URL: https://issues.apache.org/jira/browse/PHOENIX-541 Project: Phoenix Issue Type: Improvement Affects Versions: 3.0-Release Reporter: mujtaba Labels: newbie With current configuration of row-count based mutable batch size, ideal value for batch size is around 800 rather then current 15k when creating indexes based on memory consumption, CPU and GC (data size: key: ~60 bytes, 14 integer column in separate CFs) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
