[jira] [Updated] (PHOENIX-6423) Mixing default and explicit column families causes exceptions and wrong results.
[
https://issues.apache.org/jira/browse/PHOENIX-6423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Hofhansl updated PHOENIX-6423:
---
Summary: Mixing default and explicit column families causes exceptions and
wrong results. (was: Mixed column families with uncovered local index columns
causes an exception)
> Mixing default and explicit column families causes exceptions and wrong
> results.
>
>
> Key: PHOENIX-6423
> URL: https://issues.apache.org/jira/browse/PHOENIX-6423
> Project: Phoenix
> Issue Type: Bug
>Reporter: Lars Hofhansl
>Priority: Minor
>
> This one is obscure:
> {code}
> > create table test3(pk1 integer not null primary key, v1 float, y.v1
> > varchar);
> No rows affected (1.179 seconds)
> > create local index l4 on test3(v1);
> No rows affected (11.253 seconds)
> > select * from test3 where v1 < 1;
> Error: ERROR 203 (22005): Type mismatch. expected: FLOAT but was: VARCHAR at
> column: V1 (state=22005,code=203)
> org.apache.phoenix.schema.ArgumentTypeMismatchException: ERROR 203 (22005):
> Type mismatch. expected: FLOAT but was: VARCHAR at column: V1
> at
> org.apache.phoenix.compile.ProjectionCompiler.coerceIfNecessary(ProjectionCompiler.java:339)
> at
> org.apache.phoenix.compile.ProjectionCompiler.projectAllIndexColumns(ProjectionCompiler.java:258)
> at
> org.apache.phoenix.compile.ProjectionCompiler.compile(ProjectionCompiler.java:393)
> at
> org.apache.phoenix.compile.QueryCompiler.compileSingleFlatQuery(QueryCompiler.java:757)
> at
> org.apache.phoenix.compile.QueryCompiler.compileSingleQuery(QueryCompiler.java:676)
> at
> org.apache.phoenix.compile.QueryCompiler.compileSelect(QueryCompiler.java:253)
> at org.apache.phoenix.compile.QueryCompiler.compile(QueryCompiler.java:178)
> at org.apache.phoenix.optimize.QueryOptimizer.addPlan(QueryOptimizer.java:347)
> at
> org.apache.phoenix.optimize.QueryOptimizer.getApplicablePlansForSingleFlatQuery(QueryOptimizer.java:239)
> at
> org.apache.phoenix.optimize.QueryOptimizer.getApplicablePlans(QueryOptimizer.java:138)
> at
> org.apache.phoenix.optimize.QueryOptimizer.optimize(QueryOptimizer.java:116)
> at
> org.apache.phoenix.optimize.QueryOptimizer.optimize(QueryOptimizer.java:102)
> at org.apache.phoenix.jdbc.PhoenixStatement$1.call(PhoenixStatement.java:313)
> at org.apache.phoenix.jdbc.PhoenixStatement$1.call(PhoenixStatement.java:295)
> at org.apache.phoenix.call.CallRunner.run(CallRunner.java:53)
> at
> org.apache.phoenix.jdbc.PhoenixStatement.executeQuery(PhoenixStatement.java:294)
> at
> org.apache.phoenix.jdbc.PhoenixStatement.executeQuery(PhoenixStatement.java:287)
> at
> org.apache.phoenix.jdbc.PhoenixStatement.execute(PhoenixStatement.java:1930)
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (PHOENIX-6423) Mixing default and explicit column families causes exceptions and wrong results.
[
https://issues.apache.org/jira/browse/PHOENIX-6423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Hofhansl updated PHOENIX-6423:
---
Priority: Major (was: Minor)
> Mixing default and explicit column families causes exceptions and wrong
> results.
>
>
> Key: PHOENIX-6423
> URL: https://issues.apache.org/jira/browse/PHOENIX-6423
> Project: Phoenix
> Issue Type: Bug
>Reporter: Lars Hofhansl
>Priority: Major
>
> This one is obscure:
> {code}
> > create table test3(pk1 integer not null primary key, v1 float, y.v1
> > varchar);
> No rows affected (1.179 seconds)
> > create local index l4 on test3(v1);
> No rows affected (11.253 seconds)
> > select * from test3 where v1 < 1;
> Error: ERROR 203 (22005): Type mismatch. expected: FLOAT but was: VARCHAR at
> column: V1 (state=22005,code=203)
> org.apache.phoenix.schema.ArgumentTypeMismatchException: ERROR 203 (22005):
> Type mismatch. expected: FLOAT but was: VARCHAR at column: V1
> at
> org.apache.phoenix.compile.ProjectionCompiler.coerceIfNecessary(ProjectionCompiler.java:339)
> at
> org.apache.phoenix.compile.ProjectionCompiler.projectAllIndexColumns(ProjectionCompiler.java:258)
> at
> org.apache.phoenix.compile.ProjectionCompiler.compile(ProjectionCompiler.java:393)
> at
> org.apache.phoenix.compile.QueryCompiler.compileSingleFlatQuery(QueryCompiler.java:757)
> at
> org.apache.phoenix.compile.QueryCompiler.compileSingleQuery(QueryCompiler.java:676)
> at
> org.apache.phoenix.compile.QueryCompiler.compileSelect(QueryCompiler.java:253)
> at org.apache.phoenix.compile.QueryCompiler.compile(QueryCompiler.java:178)
> at org.apache.phoenix.optimize.QueryOptimizer.addPlan(QueryOptimizer.java:347)
> at
> org.apache.phoenix.optimize.QueryOptimizer.getApplicablePlansForSingleFlatQuery(QueryOptimizer.java:239)
> at
> org.apache.phoenix.optimize.QueryOptimizer.getApplicablePlans(QueryOptimizer.java:138)
> at
> org.apache.phoenix.optimize.QueryOptimizer.optimize(QueryOptimizer.java:116)
> at
> org.apache.phoenix.optimize.QueryOptimizer.optimize(QueryOptimizer.java:102)
> at org.apache.phoenix.jdbc.PhoenixStatement$1.call(PhoenixStatement.java:313)
> at org.apache.phoenix.jdbc.PhoenixStatement$1.call(PhoenixStatement.java:295)
> at org.apache.phoenix.call.CallRunner.run(CallRunner.java:53)
> at
> org.apache.phoenix.jdbc.PhoenixStatement.executeQuery(PhoenixStatement.java:294)
> at
> org.apache.phoenix.jdbc.PhoenixStatement.executeQuery(PhoenixStatement.java:287)
> at
> org.apache.phoenix.jdbc.PhoenixStatement.execute(PhoenixStatement.java:1930)
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (PHOENIX-6423) Mixed column families with uncovered local index columns causes an exception
[
https://issues.apache.org/jira/browse/PHOENIX-6423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Hofhansl updated PHOENIX-6423:
---
Description:
This one is obscure:
{code}
> create table test3(pk1 integer not null primary key, v1 float, y.v1 varchar);
No rows affected (1.179 seconds)
> create local index l4 on test3(v1);
No rows affected (11.253 seconds)
> select * from test3 where v1 < 1;
Error: ERROR 203 (22005): Type mismatch. expected: FLOAT but was: VARCHAR at
column: V1 (state=22005,code=203)
org.apache.phoenix.schema.ArgumentTypeMismatchException: ERROR 203 (22005):
Type mismatch. expected: FLOAT but was: VARCHAR at column: V1
at
org.apache.phoenix.compile.ProjectionCompiler.coerceIfNecessary(ProjectionCompiler.java:339)
at
org.apache.phoenix.compile.ProjectionCompiler.projectAllIndexColumns(ProjectionCompiler.java:258)
at
org.apache.phoenix.compile.ProjectionCompiler.compile(ProjectionCompiler.java:393)
at
org.apache.phoenix.compile.QueryCompiler.compileSingleFlatQuery(QueryCompiler.java:757)
at
org.apache.phoenix.compile.QueryCompiler.compileSingleQuery(QueryCompiler.java:676)
at
org.apache.phoenix.compile.QueryCompiler.compileSelect(QueryCompiler.java:253)
at org.apache.phoenix.compile.QueryCompiler.compile(QueryCompiler.java:178)
at org.apache.phoenix.optimize.QueryOptimizer.addPlan(QueryOptimizer.java:347)
at
org.apache.phoenix.optimize.QueryOptimizer.getApplicablePlansForSingleFlatQuery(QueryOptimizer.java:239)
at
org.apache.phoenix.optimize.QueryOptimizer.getApplicablePlans(QueryOptimizer.java:138)
at org.apache.phoenix.optimize.QueryOptimizer.optimize(QueryOptimizer.java:116)
at org.apache.phoenix.optimize.QueryOptimizer.optimize(QueryOptimizer.java:102)
at org.apache.phoenix.jdbc.PhoenixStatement$1.call(PhoenixStatement.java:313)
at org.apache.phoenix.jdbc.PhoenixStatement$1.call(PhoenixStatement.java:295)
at org.apache.phoenix.call.CallRunner.run(CallRunner.java:53)
at
org.apache.phoenix.jdbc.PhoenixStatement.executeQuery(PhoenixStatement.java:294)
at
org.apache.phoenix.jdbc.PhoenixStatement.executeQuery(PhoenixStatement.java:287)
at org.apache.phoenix.jdbc.PhoenixStatement.execute(PhoenixStatement.java:1930)
{code}
was:
This one is obscure:
{code}
> create table test3(pk1 integer not null primary key, v1 float, y.v1 varchar);
No rows affected (1.179 seconds)
> create local index l4 on test3(v1);
No rows affected (11.253 seconds)
> select * from test3 where v1 < 1;
Error: ERROR 203 (22005): Type mismatch. expected: FLOAT but was: VARCHAR at
column: V1 (state=22005,code=203)
org.apache.phoenix.schema.ArgumentTypeMismatchException: ERROR 203 (22005):
Type mismatch. expected: FLOAT but was: VARCHAR at column: V1
at
org.apache.phoenix.compile.ProjectionCompiler.coerceIfNecessary(ProjectionCompiler.java:339)
at
org.apache.phoenix.compile.ProjectionCompiler.projectAllIndexColumns(ProjectionCompiler.java:258)
at
org.apache.phoenix.compile.ProjectionCompiler.compile(ProjectionCompiler.java:393)
at
org.apache.phoenix.compile.QueryCompiler.compileSingleFlatQuery(QueryCompiler.java:757)
at
org.apache.phoenix.compile.QueryCompiler.compileSingleQuery(QueryCompiler.java:676)
at
org.apache.phoenix.compile.QueryCompiler.compileSelect(QueryCompiler.java:253)
at org.apache.phoenix.compile.QueryCompiler.compile(QueryCompiler.java:178)
at org.apache.phoenix.optimize.QueryOptimizer.addPlan(QueryOptimizer.java:347)
at
org.apache.phoenix.optimize.QueryOptimizer.getApplicablePlansForSingleFlatQuery(QueryOptimizer.java:239)
at
org.apache.phoenix.optimize.QueryOptimizer.getApplicablePlans(QueryOptimizer.java:138)
at org.apache.phoenix.optimize.QueryOptimizer.optimize(QueryOptimizer.java:116)
at org.apache.phoenix.optimize.QueryOptimizer.optimize(QueryOptimizer.java:102)
at org.apache.phoenix.jdbc.PhoenixStatement$1.call(PhoenixStatement.java:313)
at org.apache.phoenix.jdbc.PhoenixStatement$1.call(PhoenixStatement.java:295)
at org.apache.phoenix.call.CallRunner.run(CallRunner.java:53)
at
org.apache.phoenix.jdbc.PhoenixStatement.executeQuery(PhoenixStatement.java:294)
at
org.apache.phoenix.jdbc.PhoenixStatement.executeQuery(PhoenixStatement.java:287)
at org.apache.phoenix.jdbc.PhoenixStatement.execute(PhoenixStatement.java:1930)
code}
> Mixed column families with uncovered local index columns causes an exception
>
>
> Key: PHOENIX-6423
> URL: https://issues.apache.org/jira/browse/PHOENIX-6423
> Project: Phoenix
> Issue Type: Bug
>Reporter: Lars Hofhansl
>Priority: Minor
>
> This one is obscure:
> {code}
> > create table test3(pk1 integer not null primary key, v1 float, y.v1
> > varchar);
> No rows affected (1.179 seconds)
> > create local index l4 on test3(v1);
> No rows affected (11.253 seconds)
> > select * from test3 where
[jira] [Updated] (PHOENIX-6423) Mixed column families with uncovered local index columns causes an exception
[
https://issues.apache.org/jira/browse/PHOENIX-6423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Hofhansl updated PHOENIX-6423:
---
Description:
This one is obscure:
{code}
> create table test3(pk1 integer not null primary key, v1 float, y.v1 varchar);
No rows affected (1.179 seconds)
> create local index l4 on test3(v1);
No rows affected (11.253 seconds)
> select * from test3 where v1 < 1;
Error: ERROR 203 (22005): Type mismatch. expected: FLOAT but was: VARCHAR at
column: V1 (state=22005,code=203)
org.apache.phoenix.schema.ArgumentTypeMismatchException: ERROR 203 (22005):
Type mismatch. expected: FLOAT but was: VARCHAR at column: V1
at
org.apache.phoenix.compile.ProjectionCompiler.coerceIfNecessary(ProjectionCompiler.java:339)
at
org.apache.phoenix.compile.ProjectionCompiler.projectAllIndexColumns(ProjectionCompiler.java:258)
at
org.apache.phoenix.compile.ProjectionCompiler.compile(ProjectionCompiler.java:393)
at
org.apache.phoenix.compile.QueryCompiler.compileSingleFlatQuery(QueryCompiler.java:757)
at
org.apache.phoenix.compile.QueryCompiler.compileSingleQuery(QueryCompiler.java:676)
at
org.apache.phoenix.compile.QueryCompiler.compileSelect(QueryCompiler.java:253)
at org.apache.phoenix.compile.QueryCompiler.compile(QueryCompiler.java:178)
at org.apache.phoenix.optimize.QueryOptimizer.addPlan(QueryOptimizer.java:347)
at
org.apache.phoenix.optimize.QueryOptimizer.getApplicablePlansForSingleFlatQuery(QueryOptimizer.java:239)
at
org.apache.phoenix.optimize.QueryOptimizer.getApplicablePlans(QueryOptimizer.java:138)
at org.apache.phoenix.optimize.QueryOptimizer.optimize(QueryOptimizer.java:116)
at org.apache.phoenix.optimize.QueryOptimizer.optimize(QueryOptimizer.java:102)
at org.apache.phoenix.jdbc.PhoenixStatement$1.call(PhoenixStatement.java:313)
at org.apache.phoenix.jdbc.PhoenixStatement$1.call(PhoenixStatement.java:295)
at org.apache.phoenix.call.CallRunner.run(CallRunner.java:53)
at
org.apache.phoenix.jdbc.PhoenixStatement.executeQuery(PhoenixStatement.java:294)
at
org.apache.phoenix.jdbc.PhoenixStatement.executeQuery(PhoenixStatement.java:287)
at org.apache.phoenix.jdbc.PhoenixStatement.execute(PhoenixStatement.java:1930)
code}
was:
This one is obscure:
{code}
> create table test3(pk1 integer not null primary key, v1 float, y.v1
> float[10]);
No rows affected (1.179 seconds)
> create local index l4 on test3(v1);
No rows affected (11.253 seconds)
> upsert into test3 values (1,2,ARRAY[5,6]);
1 row affected (0.023 seconds)
> select * from test3 where y.v1[2] < 6;
Error: ERROR 203 (22005): Type mismatch. expected: FLOAT but was: FLOAT ARRAY
at column: V1 (state=22005,code=203)
org.apache.phoenix.schema.ArgumentTypeMismatchException: ERROR 203 (22005):
Type mismatch. expected: FLOAT but was: FLOAT ARRAY at column: V1
at
org.apache.phoenix.compile.ProjectionCompiler.coerceIfNecessary(ProjectionCompiler.java:339)
at
org.apache.phoenix.compile.ProjectionCompiler.projectAllIndexColumns(ProjectionCompiler.java:258)
at
org.apache.phoenix.compile.ProjectionCompiler.compile(ProjectionCompiler.java:393)
at
org.apache.phoenix.compile.QueryCompiler.compileSingleFlatQuery(QueryCompiler.java:757)
at
org.apache.phoenix.compile.QueryCompiler.compileSingleQuery(QueryCompiler.java:676)
at
org.apache.phoenix.compile.QueryCompiler.compileSelect(QueryCompiler.java:253)
at org.apache.phoenix.compile.QueryCompiler.compile(QueryCompiler.java:178)
at org.apache.phoenix.optimize.QueryOptimizer.addPlan(QueryOptimizer.java:347)
at
org.apache.phoenix.optimize.QueryOptimizer.getApplicablePlansForSingleFlatQuery(QueryOptimizer.java:239)
at
org.apache.phoenix.optimize.QueryOptimizer.getApplicablePlans(QueryOptimizer.java:138)
at org.apache.phoenix.optimize.QueryOptimizer.optimize(QueryOptimizer.java:116)
at org.apache.phoenix.optimize.QueryOptimizer.optimize(QueryOptimizer.java:102)
at org.apache.phoenix.jdbc.PhoenixStatement$1.call(PhoenixStatement.java:313)
at org.apache.phoenix.jdbc.PhoenixStatement$1.call(PhoenixStatement.java:295)
at org.apache.phoenix.call.CallRunner.run(CallRunner.java:53)
at
org.apache.phoenix.jdbc.PhoenixStatement.executeQuery(PhoenixStatement.java:294)
at
org.apache.phoenix.jdbc.PhoenixStatement.executeQuery(PhoenixStatement.java:287)
at org.apache.phoenix.jdbc.PhoenixStatement.execute(PhoenixStatement.java:1930)
{code}
> Mixed column families with uncovered local index columns causes an exception
>
>
> Key: PHOENIX-6423
> URL: https://issues.apache.org/jira/browse/PHOENIX-6423
> Project: Phoenix
> Issue Type: Bug
>Reporter: Lars Hofhansl
>Priority: Minor
>
> This one is obscure:
> {code}
> > create table test3(pk1 integer not null primary key, v1 float, y.v1
>
[jira] [Created] (PHOENIX-6423) Mixed column families with uncovered local index columns causes an exception
Lars Hofhansl created PHOENIX-6423:
--
Summary: Mixed column families with uncovered local index columns
causes an exception
Key: PHOENIX-6423
URL: https://issues.apache.org/jira/browse/PHOENIX-6423
Project: Phoenix
Issue Type: Bug
Reporter: Lars Hofhansl
This one is obscure:
{code}
> create table test3(pk1 integer not null primary key, v1 float, y.v1
> float[10]);
No rows affected (1.179 seconds)
> create local index l4 on test3(v1);
No rows affected (11.253 seconds)
> upsert into test3 values (1,2,ARRAY[5,6]);
1 row affected (0.023 seconds)
> select * from test3 where y.v1[2] < 6;
Error: ERROR 203 (22005): Type mismatch. expected: FLOAT but was: FLOAT ARRAY
at column: V1 (state=22005,code=203)
org.apache.phoenix.schema.ArgumentTypeMismatchException: ERROR 203 (22005):
Type mismatch. expected: FLOAT but was: FLOAT ARRAY at column: V1
at
org.apache.phoenix.compile.ProjectionCompiler.coerceIfNecessary(ProjectionCompiler.java:339)
at
org.apache.phoenix.compile.ProjectionCompiler.projectAllIndexColumns(ProjectionCompiler.java:258)
at
org.apache.phoenix.compile.ProjectionCompiler.compile(ProjectionCompiler.java:393)
at
org.apache.phoenix.compile.QueryCompiler.compileSingleFlatQuery(QueryCompiler.java:757)
at
org.apache.phoenix.compile.QueryCompiler.compileSingleQuery(QueryCompiler.java:676)
at
org.apache.phoenix.compile.QueryCompiler.compileSelect(QueryCompiler.java:253)
at org.apache.phoenix.compile.QueryCompiler.compile(QueryCompiler.java:178)
at org.apache.phoenix.optimize.QueryOptimizer.addPlan(QueryOptimizer.java:347)
at
org.apache.phoenix.optimize.QueryOptimizer.getApplicablePlansForSingleFlatQuery(QueryOptimizer.java:239)
at
org.apache.phoenix.optimize.QueryOptimizer.getApplicablePlans(QueryOptimizer.java:138)
at org.apache.phoenix.optimize.QueryOptimizer.optimize(QueryOptimizer.java:116)
at org.apache.phoenix.optimize.QueryOptimizer.optimize(QueryOptimizer.java:102)
at org.apache.phoenix.jdbc.PhoenixStatement$1.call(PhoenixStatement.java:313)
at org.apache.phoenix.jdbc.PhoenixStatement$1.call(PhoenixStatement.java:295)
at org.apache.phoenix.call.CallRunner.run(CallRunner.java:53)
at
org.apache.phoenix.jdbc.PhoenixStatement.executeQuery(PhoenixStatement.java:294)
at
org.apache.phoenix.jdbc.PhoenixStatement.executeQuery(PhoenixStatement.java:287)
at org.apache.phoenix.jdbc.PhoenixStatement.execute(PhoenixStatement.java:1930)
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: [VOTE] Release of Apache Phoenix 5.1.1 RC2
If 5.1.1 is sunk for any reason, I'd like to get PHOENIX-6421 in. (By itself it's not enough to sink the release, I think) On Wednesday, March 17, 2021, 8:53:59 PM PDT, Xinyi Yan wrote: +1 (non-binding) Besides the signature, checksum, and mvn install/verify, I built from the source and loaded the jar to my local environment. Create table/view/tenant view, upsert and select queries are working as expected. On Wed, Mar 17, 2021 at 8:32 PM Viraj Jasani wrote: > +1 (non-binding) > > * Signature: ok > * Checksum : ok > * Rat check (1.8.0_171): ok > - mvn clean apache-rat:check > * Built from source (1.8.0_171): ok > - mvn clean install -DskipTests > * Basic CRUD testing locally: ok > * Unit tests pass (1.8.0_171): failed (few flakes, passed in subsequent > run) > - mvn clean package && mvn verify -Dskip.embedded > > > On Tue, 16 Mar 2021 at 8:58 PM, Istvan Toth wrote: > > > Please vote on this Apache phoenix release candidate, > > phoenix-5.1.1RC2 > > > > The VOTE will remain open for at least 72 hours. > > > > [ ] +1 Release this package as Apache phoenix 5.1.1 > > [ ] -1 Do not release this package because ... > > > > The tag to be voted on is 5.1.1RC2: > > > > https://github.com/apache/phoenix/tree/5.1.1RC2 > > > > The release files, including signatures, digests, as well as CHANGES.md > > and RELEASENOTES.md included in this RC can be found at: > > > > https://dist.apache.org/repos/dist/dev/phoenix/phoenix-5.1.1RC2/ > > > > Maven artifacts are available in a staging repository at: > > > > https://repository.apache.org/#stagingRepositories > > (orgapachephoenix-1229) > > > > Artifacts were signed with the 0x794433C7 key which can be found in: > > > > https://dist.apache.org/repos/dist/release/phoenix/KEYS > > > > To learn more about Apache phoenix, please see > > > > http://phoenix.apache.org/ > > > > Thanks, > > Istvan > > >
[jira] [Updated] (PHOENIX-6421) Selecting an indexed array value from an uncovered column with local index returns NULL
[
https://issues.apache.org/jira/browse/PHOENIX-6421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Hofhansl updated PHOENIX-6421:
---
Fix Version/s: 5.1.2
5.2.0
4.16.1
> Selecting an indexed array value from an uncovered column with local index
> returns NULL
> ---
>
> Key: PHOENIX-6421
> URL: https://issues.apache.org/jira/browse/PHOENIX-6421
> Project: Phoenix
> Issue Type: Bug
>Reporter: Lars Hofhansl
>Priority: Major
> Fix For: 4.16.1, 5.2.0, 5.1.2
>
> Attachments: 6421-5.1.txt
>
>
> Another one of these:
> {code:java}
> > create table test1(pk1 integer not null primary key, v1 float, v2
> > float[10]);
> No rows affected (0.673 seconds)
> > create local index l2 on test1(v1);
> No rows affected (10.889 seconds)
> > upsert into test1 values(rand() * 1000, rand(), ARRAY[rand(),rand(),
> > rand()]);
> 1 row affected (0.045 seconds)
> > select /*+ NO_INDEX */ v2[1] from test1 where v1 < 1;
> +---+
> | ARRAY_ELEM(V2, 1) |
> +---+
> | 0.49338496 |
> +---+
> 1 row selected (0.037 seconds)
> > select v2[1] from test1 where v1 < 1;
> +-+
> | ARRAY_ELEM("V2", 1) |
> +-+
> | null |
> +-+
> 1 row selected (0.062 seconds)
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (PHOENIX-6421) Selecting an indexed array value from an uncovered column with local index returns NULL
[
https://issues.apache.org/jira/browse/PHOENIX-6421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Hofhansl updated PHOENIX-6421:
---
Attachment: 6421-5.1.txt
> Selecting an indexed array value from an uncovered column with local index
> returns NULL
> ---
>
> Key: PHOENIX-6421
> URL: https://issues.apache.org/jira/browse/PHOENIX-6421
> Project: Phoenix
> Issue Type: Bug
>Reporter: Lars Hofhansl
>Assignee: Lars Hofhansl
>Priority: Major
> Fix For: 4.16.1, 5.2.0, 5.1.2
>
> Attachments: 6421-5.1.txt
>
>
> Another one of these:
> {code:java}
> > create table test1(pk1 integer not null primary key, v1 float, v2
> > float[10]);
> No rows affected (0.673 seconds)
> > create local index l2 on test1(v1);
> No rows affected (10.889 seconds)
> > upsert into test1 values(rand() * 1000, rand(), ARRAY[rand(),rand(),
> > rand()]);
> 1 row affected (0.045 seconds)
> > select /*+ NO_INDEX */ v2[1] from test1 where v1 < 1;
> +---+
> | ARRAY_ELEM(V2, 1) |
> +---+
> | 0.49338496 |
> +---+
> 1 row selected (0.037 seconds)
> > select v2[1] from test1 where v1 < 1;
> +-+
> | ARRAY_ELEM("V2", 1) |
> +-+
> | null |
> +-+
> 1 row selected (0.062 seconds)
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (PHOENIX-6421) Selecting an indexed array value from an uncovered column with local index returns NULL
[
https://issues.apache.org/jira/browse/PHOENIX-6421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Hofhansl reassigned PHOENIX-6421:
--
Assignee: Lars Hofhansl
> Selecting an indexed array value from an uncovered column with local index
> returns NULL
> ---
>
> Key: PHOENIX-6421
> URL: https://issues.apache.org/jira/browse/PHOENIX-6421
> Project: Phoenix
> Issue Type: Bug
>Reporter: Lars Hofhansl
>Assignee: Lars Hofhansl
>Priority: Major
> Fix For: 4.16.1, 5.2.0, 5.1.2
>
> Attachments: 6421-5.1.txt
>
>
> Another one of these:
> {code:java}
> > create table test1(pk1 integer not null primary key, v1 float, v2
> > float[10]);
> No rows affected (0.673 seconds)
> > create local index l2 on test1(v1);
> No rows affected (10.889 seconds)
> > upsert into test1 values(rand() * 1000, rand(), ARRAY[rand(),rand(),
> > rand()]);
> 1 row affected (0.045 seconds)
> > select /*+ NO_INDEX */ v2[1] from test1 where v1 < 1;
> +---+
> | ARRAY_ELEM(V2, 1) |
> +---+
> | 0.49338496 |
> +---+
> 1 row selected (0.037 seconds)
> > select v2[1] from test1 where v1 < 1;
> +-+
> | ARRAY_ELEM("V2", 1) |
> +-+
> | null |
> +-+
> 1 row selected (0.062 seconds)
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [phoenix-omid] joshelser commented on a change in pull request #92: OMID-202 Refactor Omid to use Netty 4
joshelser commented on a change in pull request #92:
URL: https://github.com/apache/phoenix-omid/pull/92#discussion_r597882282
##
File path:
transaction-client/src/main/java/org/apache/omid/tso/client/TSOClient.java
##
@@ -342,7 +344,7 @@ public void nodeChanged() throws Exception {
setTSOAddress(hp.getHost(), hp.getPort());
epoch = Long.parseLong(currentTSOAndEpochArray[1]);
LOG.info("CurrentTSO ZNode changed. New TSO Host & Port {}/Epoch {}",
hp, getEpoch());
-if (currentChannel != null && currentChannel.isConnected()) {
+if (currentChannel != null && currentChannel.isActive()) {
Review comment:
Might be nice to consolidate this into a helper since you're modifying
it.
##
File path:
transaction-client/src/main/java/org/apache/omid/tso/client/TSOClient.java
##
@@ -513,7 +515,7 @@ void decrementRetries() {
}
public StateMachine.State handleEvent(CloseEvent e) {
-factory.releaseExternalResources();
+bootstrap.config().group().shutdownGracefully();
Review comment:
If you have two racing `CloseEvent` messages, does
`shutdownGracefully()` handle this correctly (i.e. is synchronized and exits
quietly on the 2nd).
##
File path:
transaction-client/src/main/java/org/apache/omid/tso/client/TSOClient.java
##
@@ -1012,37 +1016,34 @@ private void closeChannelAndErrorRequests() {
}
@Override
-public void channelConnected(ChannelHandlerContext ctx,
ChannelStateEvent e) {
-currentChannel = e.getChannel();
-LOG.debug("HANDLER (CHANNEL CONNECTED): Connection {}. Sending
connected event to FSM", e);
-fsm.sendEvent(new ConnectedEvent(e.getChannel()));
+public void channelActive(ChannelHandlerContext ctx) {
+currentChannel = ctx.channel();
+LOG.debug("HANDLER (CHANNEL ACTIVE): Connection {}. Sending
connected event to FSM", ctx.channel());
+fsm.sendEvent(new ConnectedEvent(ctx.channel()));
}
@Override
-public void channelDisconnected(ChannelHandlerContext ctx,
ChannelStateEvent e) throws Exception {
-LOG.debug("HANDLER (CHANNEL DISCONNECTED): Connection {}. Sending
error event to FSM", e);
+public void channelInactive(ChannelHandlerContext ctx) throws
Exception {
+LOG.debug("HANDLER (CHANNEL INACTIVE): Connection {}. Sending
error, then channelClosed event to FSM", ctx.channel());
+// Netty 3 had separate callbacks, and the FSM expects both events.
+// Sending both is much easier than rewriting the FSM
Review comment:
No issues if we send both of these events back? Still looking to see
where those are consumed.
##
File path: tso-server/src/test/java/org/apache/omid/tso/client/TSOClientRaw.java
##
@@ -58,39 +62,39 @@
private final Channel channel;
public TSOClientRaw(String host, int port) throws InterruptedException,
ExecutionException {
-// Start client with Nb of active threads = 3 as maximum.
-ChannelFactory factory = new NioClientSocketChannelFactory(
-Executors.newCachedThreadPool(
-new
ThreadFactoryBuilder().setNameFormat("tsoclient-boss-%d").build()),
-Executors.newCachedThreadPool(
-new
ThreadFactoryBuilder().setNameFormat("tsoclient-worker-%d").build()), 3);
-// Create the bootstrap
-ClientBootstrap bootstrap = new ClientBootstrap(factory);
InetSocketAddress addr = new InetSocketAddress(host, port);
-ChannelPipeline pipeline = bootstrap.getPipeline();
-pipeline.addLast("lengthbaseddecoder",
-new LengthFieldBasedFrameDecoder(8 * 1024, 0, 4, 0, 4));
-pipeline.addLast("lengthprepender", new LengthFieldPrepender(4));
-pipeline.addLast("protobufdecoder",
-new ProtobufDecoder(TSOProto.Response.getDefaultInstance()));
-pipeline.addLast("protobufencoder", new ProtobufEncoder());
-
-Handler handler = new Handler();
-pipeline.addLast("handler", handler);
-
-bootstrap.setOption("tcpNoDelay", true);
-bootstrap.setOption("keepAlive", true);
-bootstrap.setOption("reuseAddress", true);
-bootstrap.setOption("connectTimeoutMillis", 100);
+// Start client with Nb of active threads = 3
+ThreadFactory workerThreadFactory = new
ThreadFactoryBuilder().setNameFormat("tsoclient-worker-%d").build();
+EventLoopGroup workerGroup = new NioEventLoopGroup(3,
workerThreadFactory);
Review comment:
The old code appears to have had separate boss and worker thread pools.
Was the old boss pool unused?
##
File path: tso-server/src/main/java/org/apache/omid/tso/TSOChannelHandler.java
##
@@ -17,95 +17,116 @@
*/
package org.apache.omid.tso;
-import
Re: Topic suggestions for April Tech Talk
Lars, Thank you for suggestions and it will be great to see you presenting in an upcoming meeting, hopefully very soon. Josh, Thank you for volunteering for the April meeting. You are the host for it. It will be great if you can write a brief abstract/description about the meeting topic that I can send out with the meeting invitation. I do not know exactly how you want to structure the meeting but I can think of that you give a brief overview of Hue, PQS, and the Python library, explain what specific problems they address, and what challenges they have and/or what we would like to do for them in near future to initiate discussions. Thank you again! Kadir On Fri, Mar 19, 2021 at 10:39 AM la...@apache.org wrote: > An interesting topic would BigData ecosystem integration, which is clearly > one of the strengths of Phoenix. > > I.e. with Trino (formerly Presto), Spark, and classical MapReduce. Perhaps > this could cover also HBase snapshot support. > > I'm happy to cover this. But I can't to that for April 1st - juggling too > many things right now. > > -- Lars > > On Tuesday, March 9, 2021, 10:54:16 AM PST, Kadir Ozdemir < > ka...@gsuite.cloud.apache.org> wrote: > > > > > > Hi All, > > This is a friendly reminder that our next tech talk meeting will be held at > 9AM PST on April 01. If you like to present a topic for the next meeting, > please let us know by March 18. For more information about our tech talks, > and the slides and recording for the previous presentation, please visit > https://phoenix.apache.org/tech_talks.html. > > I look forward to your suggestions for the next meeting. > > Thanks, > Kadir >
Re: Topic suggestions for April Tech Talk
An interesting topic would BigData ecosystem integration, which is clearly one of the strengths of Phoenix. I.e. with Trino (formerly Presto), Spark, and classical MapReduce. Perhaps this could cover also HBase snapshot support. I'm happy to cover this. But I can't to that for April 1st - juggling too many things right now. -- Lars On Tuesday, March 9, 2021, 10:54:16 AM PST, Kadir Ozdemir wrote: Hi All, This is a friendly reminder that our next tech talk meeting will be held at 9AM PST on April 01. If you like to present a topic for the next meeting, please let us know by March 18. For more information about our tech talks, and the slides and recording for the previous presentation, please visit https://phoenix.apache.org/tech_talks.html. I look forward to your suggestions for the next meeting. Thanks, Kadir
Re: Topic suggestions for April Tech Talk
In addition to the technical implementation of the PQS an interesting topic for the PQS would be how to scale it. How many PQSs compared to the number of region servers? How to size the machine/VM? Etc. I think just that could take more than 15 minutes. :) On Thursday, March 18, 2021, 9:18:40 AM PDT, Josh Elser wrote: What I think we have now is.. * 15mins Hue * 15mins on PQS and Python I think a full hour might be too much, depends on amount of Q On 3/17/21 6:24 PM, Kadir Ozdemir wrote: > Josh, > > I will be very interested in a discussion on PQS and would like to learn > about the Python library and its integration with Hue. Do you suggest to > discuss all in one meeting? > > Thanks, > Kadir > > On Wed, Mar 17, 2021 at 2:26 PM Josh Elser wrote: > >> While we try to figure out who will give it, I think I am safe to say we >> can offer a discussion on PQS, the Phoenix Python library, and its >> integration with Hue [1]. >> >> Is this of interest? >> >> [1] >> https://urldefense.com/v3/__https://gethue.com/__;!!DCbAVzZNrAf4!QOuUB00ICNpifpvXyDyti8dJ2abET-ZDa7qbcbPi11gGN_tl7bvbiT08g0J2zRqRUA$ >> >> On 3/9/21 1:54 PM, Kadir Ozdemir wrote: >>> Hi All, >>> >>> This is a friendly reminder that our next tech talk meeting will be held >>> at 9AM PST on April 01. If you like to present a topic for the next >>> meeting, please let us know by March 18. For more information about our >>> tech talks, and the slides and recording for the previous presentation, >>> please visit >> https://urldefense.com/v3/__https://phoenix.apache.org/tech_talks.html__;!!DCbAVzZNrAf4!QOuUB00ICNpifpvXyDyti8dJ2abET-ZDa7qbcbPi11gGN_tl7bvbiT08g0I2wVK0pA$ >> >>> < >> https://urldefense.com/v3/__https://phoenix.apache.org/tech_talks.html__;!!DCbAVzZNrAf4!QOuUB00ICNpifpvXyDyti8dJ2abET-ZDa7qbcbPi11gGN_tl7bvbiT08g0I2wVK0pA$ >>> . >>> >>> I look forward to your suggestions for the next meeting. >>> >>> Thanks, >>> Kadir >> >
[jira] [Resolved] (PHOENIX-6422) Remove CorrelatePlan
[ https://issues.apache.org/jira/browse/PHOENIX-6422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Istvan Toth resolved PHOENIX-6422. -- Fix Version/s: 5.1.2 5.2.0 4.17.0 Resolution: Fixed Committed to master, 5.1, 4.x. I am not sure who should commit to 4.16. Thanks for the review [~vjasani] > Remove CorrelatePlan > > > Key: PHOENIX-6422 > URL: https://issues.apache.org/jira/browse/PHOENIX-6422 > Project: Phoenix > Issue Type: Improvement > Components: core >Affects Versions: 5.1.0, 4.16.0 >Reporter: Istvan Toth >Assignee: Istvan Toth >Priority: Minor > Fix For: 4.17.0, 5.2.0, 5.1.2 > > > CorrelatePlan is never instantiated outside tests, it seems to have been > superseded by the other join plans. > Remove it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (PHOENIX-6419) Unused getResolverForQuery() in QueryCompiler.verifySCN()
[
https://issues.apache.org/jira/browse/PHOENIX-6419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Istvan Toth resolved PHOENIX-6419.
--
Fix Version/s: 5.1.2
5.2.0
4.17.0
Resolution: Fixed
Committed to master, 5.1, 4.x.
I am not sure who should commit to 4.16.
Thanks for the reviews [~vjasani] [~gjacoby]
> Unused getResolverForQuery() in QueryCompiler.verifySCN()
> -
>
> Key: PHOENIX-6419
> URL: https://issues.apache.org/jira/browse/PHOENIX-6419
> Project: Phoenix
> Issue Type: Bug
> Components: core
>Affects Versions: 5.1.0, 4.16.0
>Reporter: Istvan Toth
>Assignee: Istvan Toth
>Priority: Trivial
> Fix For: 4.17.0, 5.2.0, 5.1.2
>
>
> in org.apache.phoenix.compile.QueryCompiler.verifySCN()
> we create a resolver that we don't use.
> {code:java}
> ColumnResolver resolver =
> FromCompiler.getResolverForQuery(select, conn);
> {code}
> AFAICT this has no side effects that we need, and should be removed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (PHOENIX-6422) Remove CorrelatePlan
Istvan Toth created PHOENIX-6422: Summary: Remove CorrelatePlan Key: PHOENIX-6422 URL: https://issues.apache.org/jira/browse/PHOENIX-6422 Project: Phoenix Issue Type: Improvement Components: core Affects Versions: 4.16.0, 5.1.0 Reporter: Istvan Toth Assignee: Istvan Toth CorrelatePlan is never instantiated outside tests, it seems to have been superseded by the other join plans. Remove it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (PHOENIX-6419) Unused getResolverForQuery() in QueryCompiler.verifySCN()
[
https://issues.apache.org/jira/browse/PHOENIX-6419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Istvan Toth reassigned PHOENIX-6419:
Assignee: Istvan Toth
> Unused getResolverForQuery() in QueryCompiler.verifySCN()
> -
>
> Key: PHOENIX-6419
> URL: https://issues.apache.org/jira/browse/PHOENIX-6419
> Project: Phoenix
> Issue Type: Bug
> Components: core
>Affects Versions: 5.1.0, 4.16.0
>Reporter: Istvan Toth
>Assignee: Istvan Toth
>Priority: Trivial
>
> in org.apache.phoenix.compile.QueryCompiler.verifySCN()
> we create a resolver that we don't use.
> {code:java}
> ColumnResolver resolver =
> FromCompiler.getResolverForQuery(select, conn);
> {code}
> AFAICT this has no side effects that we need, and should be removed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (PHOENIX-6418) Bump default HBase version on 2.4 profile to 2.4.2
[ https://issues.apache.org/jira/browse/PHOENIX-6418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viraj Jasani resolved PHOENIX-6418. --- Fix Version/s: 5.1.2 5.2.0 Resolution: Fixed Thanks for the review [~stoty] > Bump default HBase version on 2.4 profile to 2.4.2 > -- > > Key: PHOENIX-6418 > URL: https://issues.apache.org/jira/browse/PHOENIX-6418 > Project: Phoenix > Issue Type: Task >Reporter: Viraj Jasani >Assignee: Viraj Jasani >Priority: Major > Fix For: 5.2.0, 5.1.2 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
