[jira] [Commented] (PHOENIX-2756) FilteredKeyValueScanner should not implement KeyValueScanner
[ https://issues.apache.org/jira/browse/PHOENIX-2756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15191648#comment-15191648 ] churro morales commented on PHOENIX-2756: - Sure thing was thinking about that but didn't want to make a huge patch. I can create a new ticket and see what I can do about removing those dependencies. Thanks [~jamestaylor] > FilteredKeyValueScanner should not implement KeyValueScanner > > > Key: PHOENIX-2756 > URL: https://issues.apache.org/jira/browse/PHOENIX-2756 > Project: Phoenix > Issue Type: Task >Affects Versions: 4.8.0 >Reporter: churro morales > Fix For: 4.8.0 > > Attachments: PHOENIX-2756.patch > > > In HBASE-14355, the API for KeyValueScanner changed. More specifically the > method shouldUseScanner() had a signature change. Phoenix has a class: > FilteredKeyValueScanner which implements KeyValueScanner. For HBase 98, I > will put up a patch that doesn't change the API signature ( a little hacky) > but this signature change is already in HBase-1.2+. Either we can raise the > scope of KeyValueScanner to @LimitedPrivate in HBase land. Right now its > @Private so people don't assume that external services are depending on the > API. I'll look into how we can make things work in Phoenix land. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-2756) FilteredKeyValueScanner should not implement KeyValueScanner
[ https://issues.apache.org/jira/browse/PHOENIX-2756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15191645#comment-15191645 ] churro morales commented on PHOENIX-2756: - Sure thing was thinking about that but didn't want to make a huge patch. I can create a new ticket and see what I can do about removing those dependencies. Thanks [~jamestaylor] > FilteredKeyValueScanner should not implement KeyValueScanner > > > Key: PHOENIX-2756 > URL: https://issues.apache.org/jira/browse/PHOENIX-2756 > Project: Phoenix > Issue Type: Task >Affects Versions: 4.8.0 >Reporter: churro morales > Fix For: 4.8.0 > > Attachments: PHOENIX-2756.patch > > > In HBASE-14355, the API for KeyValueScanner changed. More specifically the > method shouldUseScanner() had a signature change. Phoenix has a class: > FilteredKeyValueScanner which implements KeyValueScanner. For HBase 98, I > will put up a patch that doesn't change the API signature ( a little hacky) > but this signature change is already in HBase-1.2+. Either we can raise the > scope of KeyValueScanner to @LimitedPrivate in HBase land. Right now its > @Private so people don't assume that external services are depending on the > API. I'll look into how we can make things work in Phoenix land. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-2756) FilteredKeyValueScanner should not implement KeyValueScanner
[ https://issues.apache.org/jira/browse/PHOENIX-2756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15191636#comment-15191636 ] churro morales commented on PHOENIX-2756: - Sure thing was thinking about that but didn't want to make a huge patch. I can create a new ticket and see what I can do about removing those dependencies. Thanks [~jamestaylor] > FilteredKeyValueScanner should not implement KeyValueScanner > > > Key: PHOENIX-2756 > URL: https://issues.apache.org/jira/browse/PHOENIX-2756 > Project: Phoenix > Issue Type: Task >Affects Versions: 4.8.0 >Reporter: churro morales > Fix For: 4.8.0 > > Attachments: PHOENIX-2756.patch > > > In HBASE-14355, the API for KeyValueScanner changed. More specifically the > method shouldUseScanner() had a signature change. Phoenix has a class: > FilteredKeyValueScanner which implements KeyValueScanner. For HBase 98, I > will put up a patch that doesn't change the API signature ( a little hacky) > but this signature change is already in HBase-1.2+. Either we can raise the > scope of KeyValueScanner to @LimitedPrivate in HBase land. Right now its > @Private so people don't assume that external services are depending on the > API. I'll look into how we can make things work in Phoenix land. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-2756) FilteredKeyValueScanner should not implement KeyValueScanner
[ https://issues.apache.org/jira/browse/PHOENIX-2756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15191619#comment-15191619 ] James Taylor commented on PHOENIX-2756: --- Thanks for the contribution, [~churromorales]. There's another related class in IndexMemstore named MemStoreScanner which extends NonLazyKeyValueScanner - any chance of changing that one? And then there's IndexMemStore which extends KeyValueStore - any hope with that one? Please commit, [~tdsilva]. > FilteredKeyValueScanner should not implement KeyValueScanner > > > Key: PHOENIX-2756 > URL: https://issues.apache.org/jira/browse/PHOENIX-2756 > Project: Phoenix > Issue Type: Task >Affects Versions: 4.8.0 >Reporter: churro morales > Fix For: 4.8.0 > > Attachments: PHOENIX-2756.patch > > > In HBASE-14355, the API for KeyValueScanner changed. More specifically the > method shouldUseScanner() had a signature change. Phoenix has a class: > FilteredKeyValueScanner which implements KeyValueScanner. For HBase 98, I > will put up a patch that doesn't change the API signature ( a little hacky) > but this signature change is already in HBase-1.2+. Either we can raise the > scope of KeyValueScanner to @LimitedPrivate in HBase land. Right now its > @Private so people don't assume that external services are depending on the > API. I'll look into how we can make things work in Phoenix land. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PHOENIX-2756) FilteredKeyValueScanner should not implement KeyValueScanner
[ https://issues.apache.org/jira/browse/PHOENIX-2756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Taylor updated PHOENIX-2756: -- Fix Version/s: 4.8.0 > FilteredKeyValueScanner should not implement KeyValueScanner > > > Key: PHOENIX-2756 > URL: https://issues.apache.org/jira/browse/PHOENIX-2756 > Project: Phoenix > Issue Type: Task >Affects Versions: 4.8.0 >Reporter: churro morales > Fix For: 4.8.0 > > Attachments: PHOENIX-2756.patch > > > In HBASE-14355, the API for KeyValueScanner changed. More specifically the > method shouldUseScanner() had a signature change. Phoenix has a class: > FilteredKeyValueScanner which implements KeyValueScanner. For HBase 98, I > will put up a patch that doesn't change the API signature ( a little hacky) > but this signature change is already in HBase-1.2+. Either we can raise the > scope of KeyValueScanner to @LimitedPrivate in HBase land. Right now its > @Private so people don't assume that external services are depending on the > API. I'll look into how we can make things work in Phoenix land. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (PHOENIX-2756) FilteredKeyValueScanner should not implement KeyValueScanner
[ https://issues.apache.org/jira/browse/PHOENIX-2756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15191522#comment-15191522 ] churro morales edited comment on PHOENIX-2756 at 3/11/16 9:38 PM: -- [~jamestaylor] ran tests, all passed locally was (Author: churromorales): ~jamestaylor ran tests, all passed locally > FilteredKeyValueScanner should not implement KeyValueScanner > > > Key: PHOENIX-2756 > URL: https://issues.apache.org/jira/browse/PHOENIX-2756 > Project: Phoenix > Issue Type: Task >Affects Versions: 4.8.0 >Reporter: churro morales > Attachments: PHOENIX-2756.patch > > > In HBASE-14355, the API for KeyValueScanner changed. More specifically the > method shouldUseScanner() had a signature change. Phoenix has a class: > FilteredKeyValueScanner which implements KeyValueScanner. For HBase 98, I > will put up a patch that doesn't change the API signature ( a little hacky) > but this signature change is already in HBase-1.2+. Either we can raise the > scope of KeyValueScanner to @LimitedPrivate in HBase land. Right now its > @Private so people don't assume that external services are depending on the > API. I'll look into how we can make things work in Phoenix land. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-2756) FilteredKeyValueScanner should not implement KeyValueScanner
[ https://issues.apache.org/jira/browse/PHOENIX-2756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15191522#comment-15191522 ] churro morales commented on PHOENIX-2756: - ~jamestaylor ran tests, all passed locally > FilteredKeyValueScanner should not implement KeyValueScanner > > > Key: PHOENIX-2756 > URL: https://issues.apache.org/jira/browse/PHOENIX-2756 > Project: Phoenix > Issue Type: Task >Affects Versions: 4.8.0 >Reporter: churro morales > Attachments: PHOENIX-2756.patch > > > In HBASE-14355, the API for KeyValueScanner changed. More specifically the > method shouldUseScanner() had a signature change. Phoenix has a class: > FilteredKeyValueScanner which implements KeyValueScanner. For HBase 98, I > will put up a patch that doesn't change the API signature ( a little hacky) > but this signature change is already in HBase-1.2+. Either we can raise the > scope of KeyValueScanner to @LimitedPrivate in HBase land. Right now its > @Private so people don't assume that external services are depending on the > API. I'll look into how we can make things work in Phoenix land. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-2760) Upgrade phoenix-server and phoenix-server-client to Avatica 1.7.0
[ https://issues.apache.org/jira/browse/PHOENIX-2760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15191503#comment-15191503 ] Josh Elser commented on PHOENIX-2760: - Ah, the warnings are coming from the assembly: phoenix-server/src/build/query-server-runnable.xml. The includes in there just need to be tweaked as well. > Upgrade phoenix-server and phoenix-server-client to Avatica 1.7.0 > - > > Key: PHOENIX-2760 > URL: https://issues.apache.org/jira/browse/PHOENIX-2760 > Project: Phoenix > Issue Type: Bug >Reporter: James Taylor >Assignee: Josh Elser > Fix For: 4.8.0 > > Attachments: PHOENIX-2760.patch > > > Once Avatica 1.7.0 is released, we should update our poms to use this as a > dependency instead of all of Calcite (on which we don't yet depend). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-418) Support approximate COUNT DISTINCT
[ https://issues.apache.org/jira/browse/PHOENIX-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15191489#comment-15191489 ] Sergey Soldatov commented on PHOENIX-418: - In Hive there is a 3rd party UDF implemented HyperLogLog algo. Can it be done in Phoenix in the same way? > Support approximate COUNT DISTINCT > -- > > Key: PHOENIX-418 > URL: https://issues.apache.org/jira/browse/PHOENIX-418 > Project: Phoenix > Issue Type: Task >Reporter: James Taylor >Assignee: maghamravikiran > Labels: gsoc2016 > > Support an "approximation" of count distinct to prevent having to hold on to > all distinct values (since this will not scale well when the number of > distinct values is huge). The Apache Drill folks have had some interesting > discussions on this > [here](http://mail-archives.apache.org/mod_mbox/incubator-drill-dev/201306.mbox/%3CJIRA.12650169.1369931282407.88049.1370645900553%40arcas%3E). > They recommend using [Welford's > method](http://en.wikipedia.org/wiki/Algorithms_for_calculating_variance_Online_algorithm). > I'm open to having a config option that uses exact versus approximate. I > don't have experience implementing an approximate implementation, so I'm not > sure how much state is required to keep on the server and return to the > client (other than realizing it'd be much less that returning all distinct > values and their counts). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PHOENIX-2760) Upgrade phoenix-server and phoenix-server-client to Avatica 1.7.0
[
https://issues.apache.org/jira/browse/PHOENIX-2760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Taylor updated PHOENIX-2760:
--
Attachment: PHOENIX-2760.patch
Patch that appears to work (i.e. phoenix-server and phoenix-server-client unit
tests pass, and mvn install -DskipTests works). Will need to remove the staging
repo before commit and there are some mysterious (at least to me :-) ) maven
warnings on install:
{code}
[WARNING] The following patterns were never triggered in this artifact
inclusion filter:
o 'org.apache.calcite:*'
[WARNING] The following patterns were never triggered in this artifact
inclusion filter:
o 'org.cloudera.htrace:htrace-core'
o 'org.apache.calcite:calcite-avatica*'
{code}
> Upgrade phoenix-server and phoenix-server-client to Avatica 1.7.0
> -
>
> Key: PHOENIX-2760
> URL: https://issues.apache.org/jira/browse/PHOENIX-2760
> Project: Phoenix
> Issue Type: Bug
>Reporter: James Taylor
>Assignee: Josh Elser
> Fix For: 4.8.0
>
> Attachments: PHOENIX-2760.patch
>
>
> Once Avatica 1.7.0 is released, we should update our poms to use this as a
> dependency instead of all of Calcite (on which we don't yet depend).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PHOENIX-2165) Pherf - Make zip file name and directory consistent
[ https://issues.apache.org/jira/browse/PHOENIX-2165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15191469#comment-15191469 ] ASF GitHub Bot commented on PHOENIX-2165: - Github user JamesRTaylor commented on the pull request: https://github.com/apache/phoenix/pull/106#issuecomment-195538866 Looks like this was committed already a while back. Please let us know if anything is awry, but otherwise the PR and JIRA can be closed. > Pherf - Make zip file name and directory consistent > --- > > Key: PHOENIX-2165 > URL: https://issues.apache.org/jira/browse/PHOENIX-2165 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.5.0 >Reporter: Cody Marcel >Assignee: Gabor Liptak >Priority: Trivial > Labels: newbie > Fix For: 4.8.0 > > > The pherf build produces a zip file named > phoenix-pherf-4.5.0-SNAPSHOT-cluster.zip. When unpacked the directory is > named pherf-4.5.0-SNAPSHOT-cluster. These should be consistent so so > automation can easily reason about naming conventions. > Either add "phoenix-" to the directory or remove it from the zip name. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PHOENIX-2760) Upgrade phoenix-server and phoenix-server-client to Avatica 1.7.0
James Taylor created PHOENIX-2760: - Summary: Upgrade phoenix-server and phoenix-server-client to Avatica 1.7.0 Key: PHOENIX-2760 URL: https://issues.apache.org/jira/browse/PHOENIX-2760 Project: Phoenix Issue Type: Bug Reporter: James Taylor Assignee: Josh Elser Fix For: 4.8.0 Once Avatica 1.7.0 is released, we should update our poms to use this as a dependency instead of all of Calcite (on which we don't yet depend). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] phoenix pull request: PHOENIX-2165 Make zip file name and director...
Github user JamesRTaylor commented on the pull request: https://github.com/apache/phoenix/pull/106#issuecomment-195538866 Looks like this was committed already a while back. Please let us know if anything is awry, but otherwise the PR and JIRA can be closed. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Updated] (PHOENIX-2165) Pherf - Make zip file name and directory consistent
[ https://issues.apache.org/jira/browse/PHOENIX-2165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Taylor updated PHOENIX-2165: -- Fix Version/s: 4.8.0 > Pherf - Make zip file name and directory consistent > --- > > Key: PHOENIX-2165 > URL: https://issues.apache.org/jira/browse/PHOENIX-2165 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.5.0 >Reporter: Cody Marcel >Assignee: Gabor Liptak >Priority: Trivial > Labels: newbie > Fix For: 4.8.0 > > > The pherf build produces a zip file named > phoenix-pherf-4.5.0-SNAPSHOT-cluster.zip. When unpacked the directory is > named pherf-4.5.0-SNAPSHOT-cluster. These should be consistent so so > automation can easily reason about naming conventions. > Either add "phoenix-" to the directory or remove it from the zip name. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PHOENIX-2748) CsvToKeyValueMapper used by CsvBulkLoadTool should set inner PhoenixConnection autoCommit to false explicitly
[ https://issues.apache.org/jira/browse/PHOENIX-2748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gabriel Reid resolved PHOENIX-2748. --- Resolution: Fixed Assignee: Gabriel Reid Fix Version/s: 4.8.0 Pushed to master and 4.x branches > CsvToKeyValueMapper used by CsvBulkLoadTool should set inner > PhoenixConnection autoCommit to false explicitly > - > > Key: PHOENIX-2748 > URL: https://issues.apache.org/jira/browse/PHOENIX-2748 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.6.0 > Environment: Phoenix 4.6.0-HBase-0.98, HBase 0.98.6-cdh5.3.2 >Reporter: chenglei >Assignee: Gabriel Reid >Priority: Minor > Fix For: 4.8.0 > > Attachments: PHOENIX-2748.patch > > > CsvBulkLoadTool uses CsvToKeyValueMapper to convert csv record to KeyValues > which should be inserted into target table , and CsvToKeyValueMapper gets the > KeyValues by mocking upsert sql to target table,so the PhoenixConnection's > autoCommit should be false,but CsvToKeyValueMapper does not set inner > PhoenixConnection autoCommit to false explicitly. When we set > "phoenix.connection.autoCommit" to true in > hbase-site.xml,CsvToKeyValueMapper will really execute upsert sql to target > table,which is not expected. > So CsvToKeyValueMapper should set inner PhoenixConnection autoCommit to > false explicitly,just as PhoenixIndexImportMapper does. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] phoenix pull request: PHOENIX-2165 Make zip file name and director...
Github user JamesRTaylor commented on the pull request: https://github.com/apache/phoenix/pull/106#issuecomment-195526886 @mujtabachohan - would you mind reviewing/committing? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (PHOENIX-2231) Support CREATE SEQUENCE in Phoenix/Calcite Integration
[ https://issues.apache.org/jira/browse/PHOENIX-2231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15191366#comment-15191366 ] Kaide Mu commented on PHOENIX-2231: --- I'll try it, thank you. > Support CREATE SEQUENCE in Phoenix/Calcite Integration > -- > > Key: PHOENIX-2231 > URL: https://issues.apache.org/jira/browse/PHOENIX-2231 > Project: Phoenix > Issue Type: Sub-task >Reporter: Maryann Xue > Labels: calcite > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-2231) Support CREATE SEQUENCE in Phoenix/Calcite Integration
[ https://issues.apache.org/jira/browse/PHOENIX-2231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15191309#comment-15191309 ] James Taylor commented on PHOENIX-2231: --- [~kdmu] - your best bet for verifying that it's working correctly is to write a unit test that uses the Calcite driver to create a sequence. You can copy/paste the SequenceIT.testCreateSequence() to CalciteIT to try it. Step through the current tests in a debugger for SequenceIT. Everyone is super busy with other tasks, so if you can experiment a bit on your own first, that'll help us. > Support CREATE SEQUENCE in Phoenix/Calcite Integration > -- > > Key: PHOENIX-2231 > URL: https://issues.apache.org/jira/browse/PHOENIX-2231 > Project: Phoenix > Issue Type: Sub-task >Reporter: Maryann Xue > Labels: calcite > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-2231) Support CREATE SEQUENCE in Phoenix/Calcite Integration
[
https://issues.apache.org/jira/browse/PHOENIX-2231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15191300#comment-15191300
]
Kaide Mu commented on PHOENIX-2231:
---
Hi, [~rajeshbabu]. I did the following "SqlCreateSequence" but I don't know if
I did it correctly or I'm missing things, would you mind take a look when you
have any time? Also, could you explain to me how "unparse" works?
{code:title=SqlCreateSequence.java}
public SqlCreateSequence(SqlParserPos pos,
SqlIdentifier name,
SqlNode startWith,
SqlNode incrementBy,
SqlNode cacheSize,
SqlNode minValue,
SqlNode maxValue,
SqlNode cycle,
SqlNode ifNotExists) {
super(pos);
this.name = name;
this.startWith = startWith;
this.incrementBy = incrementBy;
this.cacheSize = cacheSize;
this.minValue = minValue;
this.maxValue = maxValue;
this.cycle = cycle;
this.ifNotExists = ifNotExists;
}
public SqlOperator getOperator() {
return OPERATOR;
}
public List getOperandList() {
return ImmutableList.of(name, startWith, incrementBy, cacheSize,
minValue, maxValue, cycle, ifNotExists);
}
@Override
public void unparse(SqlWriter writer, int leftPrec, int rightPrec) {
}
}
{code}
> Support CREATE SEQUENCE in Phoenix/Calcite Integration
> --
>
> Key: PHOENIX-2231
> URL: https://issues.apache.org/jira/browse/PHOENIX-2231
> Project: Phoenix
> Issue Type: Sub-task
>Reporter: Maryann Xue
> Labels: calcite
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (PHOENIX-418) Support approximate COUNT DISTINCT
[ https://issues.apache.org/jira/browse/PHOENIX-418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] maghamravikiran reassigned PHOENIX-418: --- Assignee: maghamravikiran > Support approximate COUNT DISTINCT > -- > > Key: PHOENIX-418 > URL: https://issues.apache.org/jira/browse/PHOENIX-418 > Project: Phoenix > Issue Type: Task >Reporter: James Taylor >Assignee: maghamravikiran > Labels: gsoc2016 > > Support an "approximation" of count distinct to prevent having to hold on to > all distinct values (since this will not scale well when the number of > distinct values is huge). The Apache Drill folks have had some interesting > discussions on this > [here](http://mail-archives.apache.org/mod_mbox/incubator-drill-dev/201306.mbox/%3CJIRA.12650169.1369931282407.88049.1370645900553%40arcas%3E). > They recommend using [Welford's > method](http://en.wikipedia.org/wiki/Algorithms_for_calculating_variance_Online_algorithm). > I'm open to having a config option that uses exact versus approximate. I > don't have experience implementing an approximate implementation, so I'm not > sure how much state is required to keep on the server and return to the > client (other than realizing it'd be much less that returning all distinct > values and their counts). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PHOENIX-2757) Phoenix Can't Coerce String to Boolean
[
https://issues.apache.org/jira/browse/PHOENIX-2757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Taylor updated PHOENIX-2757:
--
Fix Version/s: 4.8.0
> Phoenix Can't Coerce String to Boolean
> --
>
> Key: PHOENIX-2757
> URL: https://issues.apache.org/jira/browse/PHOENIX-2757
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.6.0
>Reporter: Aaron Stephens
> Fix For: 4.8.0
>
>
> In the process of trying to UPSERT rows with Phoenix via Nifi, I've run into
> the following:
> {noformat}
> org.apache.phoenix.schema.ConstraintViolationException:
> org.apache.phoenix.schema.TypeMismatchException: ERROR 203 (22005): Type
> mismatch. VARCHAR cannot be coerced to BOOLEAN
> at
> org.apache.phoenix.schema.types.PDataType.throwConstraintViolationException(PDataType.java:282)
> ~[na:na]
> at
> org.apache.phoenix.schema.types.PBoolean.toObject(PBoolean.java:136) ~[na:na]
> at
> org.apache.phoenix.jdbc.PhoenixPreparedStatement.setObject(PhoenixPreparedStatement.java:442)
> ~[na:na]
> at
> org.apache.commons.dbcp.DelegatingPreparedStatement.setObject(DelegatingPreparedStatement.java:166)
> ~[na:na]
> at
> org.apache.commons.dbcp.DelegatingPreparedStatement.setObject(DelegatingPreparedStatement.java:166)
> ~[na:na]
> at
> org.apache.nifi.processors.standard.PutSQL.setParameter(PutSQL.java:728)
> ~[na:na]
> at
> org.apache.nifi.processors.standard.PutSQL.setParameters(PutSQL.java:606)
> ~[na:na]
> at
> org.apache.nifi.processors.standard.PutSQL.onTrigger(PutSQL.java:223) ~[na:na]
> at
> org.apache.nifi.processor.AbstractProcessor.onTrigger(AbstractProcessor.java:27)
> ~[nifi-api-0.4.1.jar:0.4.1]
> at
> org.apache.nifi.controller.StandardProcessorNode.onTrigger(StandardProcessorNode.java:1146)
> ~[nifi-framework-core-0.4.1.jar:0.4.1]
> at
> org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:139)
> [nifi-framework-core-0.4.1.jar:0.4.1]
> at
> org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:49)
> [nifi-framework-core-0.4.1.jar:0.4.1]
> at
> org.apache.nifi.controller.scheduling.TimerDrivenSchedulingAgent$1.run(TimerDrivenSchedulingAgent.java:119)
> [nifi-framework-core-0.4.1.jar:0.4.1]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> [na:1.7.0_79]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304)
> [na:1.7.0_79]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
> [na:1.7.0_79]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> [na:1.7.0_79]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> [na:1.7.0_79]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> [na:1.7.0_79]
> at java.lang.Thread.run(Thread.java:745) [na:1.7.0_79]
> Caused by: org.apache.phoenix.schema.TypeMismatchException: ERROR 203
> (22005): Type mismatch. VARCHAR cannot be coerced to BOOLEAN
> at
> org.apache.phoenix.exception.SQLExceptionCode$1.newException(SQLExceptionCode.java:71)
> ~[na:na]
> at
> org.apache.phoenix.exception.SQLExceptionInfo.buildException(SQLExceptionInfo.java:145)
> ~[na:na]
> ... 20 common frames omitted
> {noformat}
> It appears that Phoenix currently does not know how to coerce a String into a
> Boolean (see
> [here|https://github.com/apache/phoenix/blob/master/phoenix-core/src/main/java/org/apache/phoenix/schema/types/PBoolean.java#L124-L137]).
> This is a feature that's present in other drivers such as PostgreSQL.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PHOENIX-2743) HivePhoenixHandler for big-big join with predicate push down
[ https://issues.apache.org/jira/browse/PHOENIX-2743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15191062#comment-15191062 ] James Taylor commented on PHOENIX-2743: --- [~mini666] - with our 4.7 release, the validation check done by MutationState is only done once per call to commit. You can also prevent the RPC we do to check if the client has the current metadata through the UPDATE_CACHE_FREQUENCY property (see https://phoenix.apache.org/language/index.html#options). Please let me know if there's still an issue with 4.7.0 release - otherwise let's come up with some other solution to prevents having to change MutationState. > HivePhoenixHandler for big-big join with predicate push down > > > Key: PHOENIX-2743 > URL: https://issues.apache.org/jira/browse/PHOENIX-2743 > Project: Phoenix > Issue Type: New Feature >Affects Versions: 4.5.0, 4.6.0 > Environment: hive-1.2.1 >Reporter: JeongMin Ju > Labels: features, performance > Original Estimate: 168h > Remaining Estimate: 168h > > Phoenix support hash join & sort-merge join. But in case of big*big join does > not process well. > Therefore Need other method like Hive. > I implemented hive-phoenix-handler that can access Apache Phoenix table on > HBase using HiveQL. > hive-phoenix-handler is very faster than hive-hbase-handler because of > applying predicate push down. > I am publishing source code to github for contribution and maybe will be > completed by next week. > https://github.com/mini666/hive-phoenix-handler > please, review my proposal. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-2757) Phoenix Can't Coerce String to Boolean
[
https://issues.apache.org/jira/browse/PHOENIX-2757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15191047#comment-15191047
]
James Taylor commented on PHOENIX-2757:
---
Agreed - let's start with PhoenixStatement#setObject handling the conversion of
strings first. Would be good to have consistency between CSV Bulk Loader and
setObject in how a String is converted to an Object. See
CsvUpsertExecutor.SimpleDatatypeConversionFunction for CSV Bulk Loader. We
should take into account the Format stored on PhoenixConnection through
getFormatter(PDataType type) method, as we support a connection property that
determines the format we expect. We also have the underlying capability in
{{PDataType.toObject(String}}, but should really have something like
{{PDataType.toObject(String, Format}}.
> Phoenix Can't Coerce String to Boolean
> --
>
> Key: PHOENIX-2757
> URL: https://issues.apache.org/jira/browse/PHOENIX-2757
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.6.0
>Reporter: Aaron Stephens
>
> In the process of trying to UPSERT rows with Phoenix via Nifi, I've run into
> the following:
> {noformat}
> org.apache.phoenix.schema.ConstraintViolationException:
> org.apache.phoenix.schema.TypeMismatchException: ERROR 203 (22005): Type
> mismatch. VARCHAR cannot be coerced to BOOLEAN
> at
> org.apache.phoenix.schema.types.PDataType.throwConstraintViolationException(PDataType.java:282)
> ~[na:na]
> at
> org.apache.phoenix.schema.types.PBoolean.toObject(PBoolean.java:136) ~[na:na]
> at
> org.apache.phoenix.jdbc.PhoenixPreparedStatement.setObject(PhoenixPreparedStatement.java:442)
> ~[na:na]
> at
> org.apache.commons.dbcp.DelegatingPreparedStatement.setObject(DelegatingPreparedStatement.java:166)
> ~[na:na]
> at
> org.apache.commons.dbcp.DelegatingPreparedStatement.setObject(DelegatingPreparedStatement.java:166)
> ~[na:na]
> at
> org.apache.nifi.processors.standard.PutSQL.setParameter(PutSQL.java:728)
> ~[na:na]
> at
> org.apache.nifi.processors.standard.PutSQL.setParameters(PutSQL.java:606)
> ~[na:na]
> at
> org.apache.nifi.processors.standard.PutSQL.onTrigger(PutSQL.java:223) ~[na:na]
> at
> org.apache.nifi.processor.AbstractProcessor.onTrigger(AbstractProcessor.java:27)
> ~[nifi-api-0.4.1.jar:0.4.1]
> at
> org.apache.nifi.controller.StandardProcessorNode.onTrigger(StandardProcessorNode.java:1146)
> ~[nifi-framework-core-0.4.1.jar:0.4.1]
> at
> org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:139)
> [nifi-framework-core-0.4.1.jar:0.4.1]
> at
> org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:49)
> [nifi-framework-core-0.4.1.jar:0.4.1]
> at
> org.apache.nifi.controller.scheduling.TimerDrivenSchedulingAgent$1.run(TimerDrivenSchedulingAgent.java:119)
> [nifi-framework-core-0.4.1.jar:0.4.1]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> [na:1.7.0_79]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304)
> [na:1.7.0_79]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
> [na:1.7.0_79]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> [na:1.7.0_79]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> [na:1.7.0_79]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> [na:1.7.0_79]
> at java.lang.Thread.run(Thread.java:745) [na:1.7.0_79]
> Caused by: org.apache.phoenix.schema.TypeMismatchException: ERROR 203
> (22005): Type mismatch. VARCHAR cannot be coerced to BOOLEAN
> at
> org.apache.phoenix.exception.SQLExceptionCode$1.newException(SQLExceptionCode.java:71)
> ~[na:na]
> at
> org.apache.phoenix.exception.SQLExceptionInfo.buildException(SQLExceptionInfo.java:145)
> ~[na:na]
> ... 20 common frames omitted
> {noformat}
> It appears that Phoenix currently does not know how to coerce a String into a
> Boolean (see
> [here|https://github.com/apache/phoenix/blob/master/phoenix-core/src/main/java/org/apache/phoenix/schema/types/PBoolean.java#L124-L137]).
> This is a feature that's present in other drivers such as PostgreSQL.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PHOENIX-2748) CsvToKeyValueMapper used by CsvBulkLoadTool should set inner PhoenixConnection autoCommit to false explicitly
[ https://issues.apache.org/jira/browse/PHOENIX-2748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15191012#comment-15191012 ] James Taylor commented on PHOENIX-2748: --- +1 > CsvToKeyValueMapper used by CsvBulkLoadTool should set inner > PhoenixConnection autoCommit to false explicitly > - > > Key: PHOENIX-2748 > URL: https://issues.apache.org/jira/browse/PHOENIX-2748 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.6.0 > Environment: Phoenix 4.6.0-HBase-0.98, HBase 0.98.6-cdh5.3.2 >Reporter: chenglei >Priority: Minor > Attachments: PHOENIX-2748.patch > > > CsvBulkLoadTool uses CsvToKeyValueMapper to convert csv record to KeyValues > which should be inserted into target table , and CsvToKeyValueMapper gets the > KeyValues by mocking upsert sql to target table,so the PhoenixConnection's > autoCommit should be false,but CsvToKeyValueMapper does not set inner > PhoenixConnection autoCommit to false explicitly. When we set > "phoenix.connection.autoCommit" to true in > hbase-site.xml,CsvToKeyValueMapper will really execute upsert sql to target > table,which is not expected. > So CsvToKeyValueMapper should set inner PhoenixConnection autoCommit to > false explicitly,just as PhoenixIndexImportMapper does. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PHOENIX-2748) CsvToKeyValueMapper used by CsvBulkLoadTool should set inner PhoenixConnection autoCommit to false explicitly
[ https://issues.apache.org/jira/browse/PHOENIX-2748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gabriel Reid updated PHOENIX-2748: -- Attachment: PHOENIX-2748.patch Trivial patch for this > CsvToKeyValueMapper used by CsvBulkLoadTool should set inner > PhoenixConnection autoCommit to false explicitly > - > > Key: PHOENIX-2748 > URL: https://issues.apache.org/jira/browse/PHOENIX-2748 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.6.0 > Environment: Phoenix 4.6.0-HBase-0.98, HBase 0.98.6-cdh5.3.2 >Reporter: chenglei >Priority: Minor > Attachments: PHOENIX-2748.patch > > > CsvBulkLoadTool uses CsvToKeyValueMapper to convert csv record to KeyValues > which should be inserted into target table , and CsvToKeyValueMapper gets the > KeyValues by mocking upsert sql to target table,so the PhoenixConnection's > autoCommit should be false,but CsvToKeyValueMapper does not set inner > PhoenixConnection autoCommit to false explicitly. When we set > "phoenix.connection.autoCommit" to true in > hbase-site.xml,CsvToKeyValueMapper will really execute upsert sql to target > table,which is not expected. > So CsvToKeyValueMapper should set inner PhoenixConnection autoCommit to > false explicitly,just as PhoenixIndexImportMapper does. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-2743) HivePhoenixHandler for big-big join with predicate push down
[ https://issues.apache.org/jira/browse/PHOENIX-2743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15190653#comment-15190653 ] Sergey Soldatov commented on PHOENIX-2743: -- It would be really nice since there are a lot of people who are still using older versions of Hive and who may be interested in this functionality. > HivePhoenixHandler for big-big join with predicate push down > > > Key: PHOENIX-2743 > URL: https://issues.apache.org/jira/browse/PHOENIX-2743 > Project: Phoenix > Issue Type: New Feature >Affects Versions: 4.5.0, 4.6.0 > Environment: hive-1.2.1 >Reporter: JeongMin Ju > Labels: features, performance > Original Estimate: 168h > Remaining Estimate: 168h > > Phoenix support hash join & sort-merge join. But in case of big*big join does > not process well. > Therefore Need other method like Hive. > I implemented hive-phoenix-handler that can access Apache Phoenix table on > HBase using HiveQL. > hive-phoenix-handler is very faster than hive-hbase-handler because of > applying predicate push down. > I am publishing source code to github for contribution and maybe will be > completed by next week. > https://github.com/mini666/hive-phoenix-handler > please, review my proposal. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-2743) HivePhoenixHandler for big-big join with predicate push down
[ https://issues.apache.org/jira/browse/PHOENIX-2743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15190651#comment-15190651 ] Sergey Soldatov commented on PHOENIX-2743: -- It would be really nice since there are a lot of people who are still using older versions of Hive and who may be interested in this functionality. > HivePhoenixHandler for big-big join with predicate push down > > > Key: PHOENIX-2743 > URL: https://issues.apache.org/jira/browse/PHOENIX-2743 > Project: Phoenix > Issue Type: New Feature >Affects Versions: 4.5.0, 4.6.0 > Environment: hive-1.2.1 >Reporter: JeongMin Ju > Labels: features, performance > Original Estimate: 168h > Remaining Estimate: 168h > > Phoenix support hash join & sort-merge join. But in case of big*big join does > not process well. > Therefore Need other method like Hive. > I implemented hive-phoenix-handler that can access Apache Phoenix table on > HBase using HiveQL. > hive-phoenix-handler is very faster than hive-hbase-handler because of > applying predicate push down. > I am publishing source code to github for contribution and maybe will be > completed by next week. > https://github.com/mini666/hive-phoenix-handler > please, review my proposal. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-2757) Phoenix Can't Coerce String to Boolean
[
https://issues.apache.org/jira/browse/PHOENIX-2757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15190648#comment-15190648
]
Sergey Soldatov commented on PHOENIX-2757:
--
[~randerzander] do you mean that they got an exception in setObject?
> Phoenix Can't Coerce String to Boolean
> --
>
> Key: PHOENIX-2757
> URL: https://issues.apache.org/jira/browse/PHOENIX-2757
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.6.0
>Reporter: Aaron Stephens
>
> In the process of trying to UPSERT rows with Phoenix via Nifi, I've run into
> the following:
> {noformat}
> org.apache.phoenix.schema.ConstraintViolationException:
> org.apache.phoenix.schema.TypeMismatchException: ERROR 203 (22005): Type
> mismatch. VARCHAR cannot be coerced to BOOLEAN
> at
> org.apache.phoenix.schema.types.PDataType.throwConstraintViolationException(PDataType.java:282)
> ~[na:na]
> at
> org.apache.phoenix.schema.types.PBoolean.toObject(PBoolean.java:136) ~[na:na]
> at
> org.apache.phoenix.jdbc.PhoenixPreparedStatement.setObject(PhoenixPreparedStatement.java:442)
> ~[na:na]
> at
> org.apache.commons.dbcp.DelegatingPreparedStatement.setObject(DelegatingPreparedStatement.java:166)
> ~[na:na]
> at
> org.apache.commons.dbcp.DelegatingPreparedStatement.setObject(DelegatingPreparedStatement.java:166)
> ~[na:na]
> at
> org.apache.nifi.processors.standard.PutSQL.setParameter(PutSQL.java:728)
> ~[na:na]
> at
> org.apache.nifi.processors.standard.PutSQL.setParameters(PutSQL.java:606)
> ~[na:na]
> at
> org.apache.nifi.processors.standard.PutSQL.onTrigger(PutSQL.java:223) ~[na:na]
> at
> org.apache.nifi.processor.AbstractProcessor.onTrigger(AbstractProcessor.java:27)
> ~[nifi-api-0.4.1.jar:0.4.1]
> at
> org.apache.nifi.controller.StandardProcessorNode.onTrigger(StandardProcessorNode.java:1146)
> ~[nifi-framework-core-0.4.1.jar:0.4.1]
> at
> org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:139)
> [nifi-framework-core-0.4.1.jar:0.4.1]
> at
> org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:49)
> [nifi-framework-core-0.4.1.jar:0.4.1]
> at
> org.apache.nifi.controller.scheduling.TimerDrivenSchedulingAgent$1.run(TimerDrivenSchedulingAgent.java:119)
> [nifi-framework-core-0.4.1.jar:0.4.1]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> [na:1.7.0_79]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304)
> [na:1.7.0_79]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
> [na:1.7.0_79]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> [na:1.7.0_79]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> [na:1.7.0_79]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> [na:1.7.0_79]
> at java.lang.Thread.run(Thread.java:745) [na:1.7.0_79]
> Caused by: org.apache.phoenix.schema.TypeMismatchException: ERROR 203
> (22005): Type mismatch. VARCHAR cannot be coerced to BOOLEAN
> at
> org.apache.phoenix.exception.SQLExceptionCode$1.newException(SQLExceptionCode.java:71)
> ~[na:na]
> at
> org.apache.phoenix.exception.SQLExceptionInfo.buildException(SQLExceptionInfo.java:145)
> ~[na:na]
> ... 20 common frames omitted
> {noformat}
> It appears that Phoenix currently does not know how to coerce a String into a
> Boolean (see
> [here|https://github.com/apache/phoenix/blob/master/phoenix-core/src/main/java/org/apache/phoenix/schema/types/PBoolean.java#L124-L137]).
> This is a feature that's present in other drivers such as PostgreSQL.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
