date:20171130

[jira] [Commented] (CALCITE-2074) Simplification of AND/OR expressions yields wrong results

2017-11-30 Thread Jesus Camacho Rodriguez (JIRA)


[ 
https://issues.apache.org/jira/browse/CALCITE-2074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16274064#comment-16274064
 ] 

Jesus Camacho Rodriguez commented on CALCITE-2074:
--

[~julianhyde], I think this is serious enough to block the release? Let me know 
what you think. Thanks

> Simplification of AND/OR expressions yields wrong results
> -
>
> Key: CALCITE-2074
> URL: https://issues.apache.org/jira/browse/CALCITE-2074
> Project: Calcite
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.15.0
>Reporter: Jesus Camacho Rodriguez
>Assignee: Julian Hyde
>
> Discovered while testing 1.15.0 RC0 with Hive. It seems this regression was 
> introduced by CALCITE-1995.
> Consider the following query:
> {code}
> select * from (
> select a.*,b.d d1,c.d d2 from
>   t1 a join t2 b on (a.id1 = b.id)
>join t2 c on (a.id2 = b.id) where b.d <= 1 and c.d <= 1
> ) z where d1 > 1 or d2 > 1
> {code}
> We end up generating the following plan:
> {code}
> HiveProject(id1=[$0], id2=[$1], d1=[$3], d2=[$4])
>   HiveJoin(condition=[OR(=($3, 1), =($4, 1))], joinType=[inner], 
> algorithm=[none], cost=[not available])
> HiveJoin(condition=[AND(=($0, $2), =($1, $2))], joinType=[inner], 
> algorithm=[none], cost=[not available])
>   HiveFilter(condition=[AND(IS NOT NULL($0), IS NOT NULL($1))])
> HiveProject(id1=[$0], id2=[$1])
>   HiveTableScan(table=[[default.t1]], table:alias=[a])
>   HiveFilter(condition=[AND(<=($1, 1), IS NOT NULL($0))])
> HiveProject(id=[$0], d=[$1])
>   HiveTableScan(table=[[default.t2]], table:alias=[b])
> HiveFilter(condition=[<=($0, 1)])
>   HiveProject(d=[$1])
> HiveTableScan(table=[[default.t2]], table:alias=[c])
> {code}
> Observe that the condition in the top join is not correct.
> I can reproduce this in {{RexProgramTest.simplifyFilter}} with the following 
> example:
> {code}
> // condition "a > 5 or b > 5"
> // with pre-condition "a <= 5 and b <= 5"
> // should yield "false" but yields "a = 5 or b = 5"
> checkSimplifyFilter(or(gt(aRef, literal5),gt(bRef, literal5)),
> RelOptPredicateList.of(rexBuilder,
> ImmutableList.of(le(aRef, literal5), le(bRef, literal5))),
> "false");
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (CALCITE-2074) Simplification of AND/OR expressions yields wrong results

2017-11-30 Thread Jesus Camacho Rodriguez (JIRA)

Jesus Camacho Rodriguez created CALCITE-2074:


 Summary: Simplification of AND/OR expressions yields wrong results
 Key: CALCITE-2074
 URL: https://issues.apache.org/jira/browse/CALCITE-2074
 Project: Calcite
  Issue Type: Bug
  Components: core
Affects Versions: 1.15.0
Reporter: Jesus Camacho Rodriguez
Assignee: Julian Hyde


Discovered while testing 1.15.0 RC0 with Hive. It seems this regression was 
introduced by CALCITE-1995.

Consider the following query:
{code}
select * from (
select a.*,b.d d1,c.d d2 from
  t1 a join t2 b on (a.id1 = b.id)
   join t2 c on (a.id2 = b.id) where b.d <= 1 and c.d <= 1
) z where d1 > 1 or d2 > 1
{code}

We end up generating the following plan:
{code}
HiveProject(id1=[$0], id2=[$1], d1=[$3], d2=[$4])
  HiveJoin(condition=[OR(=($3, 1), =($4, 1))], joinType=[inner], 
algorithm=[none], cost=[not available])
HiveJoin(condition=[AND(=($0, $2), =($1, $2))], joinType=[inner], 
algorithm=[none], cost=[not available])
  HiveFilter(condition=[AND(IS NOT NULL($0), IS NOT NULL($1))])
HiveProject(id1=[$0], id2=[$1])
  HiveTableScan(table=[[default.t1]], table:alias=[a])
  HiveFilter(condition=[AND(<=($1, 1), IS NOT NULL($0))])
HiveProject(id=[$0], d=[$1])
  HiveTableScan(table=[[default.t2]], table:alias=[b])
HiveFilter(condition=[<=($0, 1)])
  HiveProject(d=[$1])
HiveTableScan(table=[[default.t2]], table:alias=[c])
{code}
Observe that the condition in the top join is not correct.

I can reproduce this in {{RexProgramTest.simplifyFilter}} with the following 
example:
{code}
// condition "a > 5 or b > 5"
// with pre-condition "a <= 5 and b <= 5"
// should yield "false" but yields "a = 5 or b = 5"
checkSimplifyFilter(or(gt(aRef, literal5),gt(bRef, literal5)),
RelOptPredicateList.of(rexBuilder,
ImmutableList.of(le(aRef, literal5), le(bRef, literal5))),
"false");
{code}





--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CALCITE-2069) RexSimplify.removeNullabilityCast() always removes cast for operand with ANY type

2017-11-30 Thread Julian Hyde (JIRA)


[ 
https://issues.apache.org/jira/browse/CALCITE-2069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16273774#comment-16273774
 ] 

Julian Hyde commented on CALCITE-2069:
--

OK, thanks everyone; it sounds as if this won't break Drill or Dremio. When we 
have the last fix-up from [~vvysotskyi] this can go in.

> RexSimplify.removeNullabilityCast() always removes cast for operand with ANY 
> type
> -
>
> Key: CALCITE-2069
> URL: https://issues.apache.org/jira/browse/CALCITE-2069
> Project: Calcite
>  Issue Type: Bug
>Reporter: Volodymyr Vysotskyi
>Assignee: Julian Hyde
> Fix For: 1.16.0
>
>
> When a field is received from Dynamic Table, its type left {{ANY}}, and it is 
> used in the filter condition with the cast, which actually should produce 
> physical cast (for example we are trying to cast varchar to boolean) 
> {{RexSimplify.removeNullabilityCast()}} removes this cast and lefts only 
> field in condition.
> This test helps to observe this issue:
> {code:java}
>   @Test public void testFilterCastAny() {
> final RelBuilder builder = RelBuilder.create(config().build());
> final RelDataType intType = 
> builder.getTypeFactory().createSqlType(SqlTypeName.ANY);
> RelNode root =
> builder.scan("EMP")
> .filter(
> builder.cast(
> builder.patternField("varchar_field", intType, 0),
> SqlTypeName.BOOLEAN))
> .build();
> assertThat(str(root),
> is("LogicalFilter(condition=[CAST(varchar_field.$0):BOOLEAN NOT 
> NULL])\n"
> + "  LogicalTableScan(table=[[scott, EMP]])\n"));
>   }
> {code}
> It happens because {{SqlTypeUtil.equalSansNullability()}} returns true if any 
> of its arguments has {{ANY}} type.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (CALCITE-2069) RexSimplify.removeNullabilityCast() always removes cast for operand with ANY type

2017-11-30 Thread Julian Hyde (JIRA)


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

Julian Hyde updated CALCITE-2069:
-
Fix Version/s: 1.16.0

> RexSimplify.removeNullabilityCast() always removes cast for operand with ANY 
> type
> -
>
> Key: CALCITE-2069
> URL: https://issues.apache.org/jira/browse/CALCITE-2069
> Project: Calcite
>  Issue Type: Bug
>Reporter: Volodymyr Vysotskyi
>Assignee: Julian Hyde
> Fix For: 1.16.0
>
>
> When a field is received from Dynamic Table, its type left {{ANY}}, and it is 
> used in the filter condition with the cast, which actually should produce 
> physical cast (for example we are trying to cast varchar to boolean) 
> {{RexSimplify.removeNullabilityCast()}} removes this cast and lefts only 
> field in condition.
> This test helps to observe this issue:
> {code:java}
>   @Test public void testFilterCastAny() {
> final RelBuilder builder = RelBuilder.create(config().build());
> final RelDataType intType = 
> builder.getTypeFactory().createSqlType(SqlTypeName.ANY);
> RelNode root =
> builder.scan("EMP")
> .filter(
> builder.cast(
> builder.patternField("varchar_field", intType, 0),
> SqlTypeName.BOOLEAN))
> .build();
> assertThat(str(root),
> is("LogicalFilter(condition=[CAST(varchar_field.$0):BOOLEAN NOT 
> NULL])\n"
> + "  LogicalTableScan(table=[[scott, EMP]])\n"));
>   }
> {code}
> It happens because {{SqlTypeUtil.equalSansNullability()}} returns true if any 
> of its arguments has {{ANY}} type.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CALCITE-2069) RexSimplify.removeNullabilityCast() always removes cast for operand with ANY type

2017-11-30 Thread Laurent Goujon (JIRA)


[ 
https://issues.apache.org/jira/browse/CALCITE-2069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16273705#comment-16273705
 ] 

Laurent Goujon commented on CALCITE-2069:
-

I did not observe any regression with our own test suite, but maybe we are 
hitting the same limitation as [~amansinha100] (although we are on Calcite 
1.12.0). 

> RexSimplify.removeNullabilityCast() always removes cast for operand with ANY 
> type
> -
>
> Key: CALCITE-2069
> URL: https://issues.apache.org/jira/browse/CALCITE-2069
> Project: Calcite
>  Issue Type: Bug
>Reporter: Volodymyr Vysotskyi
>Assignee: Julian Hyde
>
> When a field is received from Dynamic Table, its type left {{ANY}}, and it is 
> used in the filter condition with the cast, which actually should produce 
> physical cast (for example we are trying to cast varchar to boolean) 
> {{RexSimplify.removeNullabilityCast()}} removes this cast and lefts only 
> field in condition.
> This test helps to observe this issue:
> {code:java}
>   @Test public void testFilterCastAny() {
> final RelBuilder builder = RelBuilder.create(config().build());
> final RelDataType intType = 
> builder.getTypeFactory().createSqlType(SqlTypeName.ANY);
> RelNode root =
> builder.scan("EMP")
> .filter(
> builder.cast(
> builder.patternField("varchar_field", intType, 0),
> SqlTypeName.BOOLEAN))
> .build();
> assertThat(str(root),
> is("LogicalFilter(condition=[CAST(varchar_field.$0):BOOLEAN NOT 
> NULL])\n"
> + "  LogicalTableScan(table=[[scott, EMP]])\n"));
>   }
> {code}
> It happens because {{SqlTypeUtil.equalSansNullability()}} returns true if any 
> of its arguments has {{ANY}} type.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CALCITE-2072) Allow specification of geospatial functions in connection string

2017-11-30 Thread Julian Hyde (JIRA)


[ 
https://issues.apache.org/jira/browse/CALCITE-2072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16273667#comment-16273667
 ] 

Julian Hyde commented on CALCITE-2072:
--

We already support comma-separated lists, e.g. {{fun=standard,oracle}}; but 
there are only two tables currently. See 
{{CalciteConnectionConfigImpl.operatorTable(String)}}.

I should have added operator tables when I added the "Extensibility" section of 
the [Adapters page|http://calcite.apache.org/docs/adapter.html] (this won't be 
published until after 1.15 but you can see a 
[preview|https://github.com/apache/calcite/blob/master/site/_docs/adapter.md#extensibility])
 but I forgot. Can someone please add a sub-section?

> Allow specification of geospatial functions in connection string
> 
>
> Key: CALCITE-2072
> URL: https://issues.apache.org/jira/browse/CALCITE-2072
> Project: Calcite
>  Issue Type: Bug
>  Components: core
>Reporter: Michael Mior
>Assignee: Julian Hyde
>
> Per Julian's suggestion, it would be good if in addition to {{fun=oracle}}, 
> we could allow fun={{spatial}} and also a comma-separated list of possible 
> operator tables.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (CALCITE-2073) Allow disabling of protobuf generation

2017-11-30 Thread Josh Elser (JIRA)


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

Josh Elser resolved CALCITE-2073.
-
Resolution: Fixed

Fixed in 
https://git-wip-us.apache.org/repos/asf?p=calcite-avatica.git;a=commit;h=cc3605e2af6ee242c70f72e330f2c12a77b8bf44

> Allow disabling of protobuf generation
> --
>
> Key: CALCITE-2073
> URL: https://issues.apache.org/jira/browse/CALCITE-2073
> Project: Calcite
>  Issue Type: Task
>  Components: avatica
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Trivial
> Fix For: avatica-1.11.0
>
>
> The xolstice maven-protobuf-plugin has a runtime dependency on a specific 
> glibc version which fails on older OS versions (notably Centos6).
> For most builds, it's unnecessary to regenerate the protobuf "specs" into 
> Java code. We can add an option for individuals to disable this.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CALCITE-2073) Allow disabling of protobuf generation

2017-11-30 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/CALCITE-2073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16273241#comment-16273241
 ] 

ASF GitHub Bot commented on CALCITE-2073:
-

Github user asfgit closed the pull request at:

https://github.com/apache/calcite-avatica/pull/19


> Allow disabling of protobuf generation
> --
>
> Key: CALCITE-2073
> URL: https://issues.apache.org/jira/browse/CALCITE-2073
> Project: Calcite
>  Issue Type: Task
>  Components: avatica
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Trivial
> Fix For: avatica-1.11.0
>
>
> The xolstice maven-protobuf-plugin has a runtime dependency on a specific 
> glibc version which fails on older OS versions (notably Centos6).
> For most builds, it's unnecessary to regenerate the protobuf "specs" into 
> Java code. We can add an option for individuals to disable this.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CALCITE-2073) Allow disabling of protobuf generation

2017-11-30 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/CALCITE-2073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16273097#comment-16273097
 ] 

ASF GitHub Bot commented on CALCITE-2073:
-

GitHub user joshelser opened a pull request:

https://github.com/apache/calcite-avatica/pull/19

CALCITE-2073 Allow disabling of the maven-protobuf-plugin

Protobuf compilation will still run by default, but users can disable it by 
providing `-P!compile-protobuf`.

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

$ git pull https://github.com/joshelser/calcite-avatica 
2073-protobuf-gen-disable

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

https://github.com/apache/calcite-avatica/pull/19.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #19


commit be2d056bbfc588a595a9ca1f5f5b62dfdff5d415
Author: Josh Elser 
Date:   2017-11-30T18:11:15Z

[CALCITE-2073] Allow disabling of the maven-protobuf-plugin




> Allow disabling of protobuf generation
> --
>
> Key: CALCITE-2073
> URL: https://issues.apache.org/jira/browse/CALCITE-2073
> Project: Calcite
>  Issue Type: Task
>  Components: avatica
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Trivial
> Fix For: avatica-1.11.0
>
>
> The xolstice maven-protobuf-plugin has a runtime dependency on a specific 
> glibc version which fails on older OS versions (notably Centos6).
> For most builds, it's unnecessary to regenerate the protobuf "specs" into 
> Java code. We can add an option for individuals to disable this.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (CALCITE-2073) Allow disabling of protobuf generation

2017-11-30 Thread Josh Elser (JIRA)

Josh Elser created CALCITE-2073:
---

 Summary: Allow disabling of protobuf generation
 Key: CALCITE-2073
 URL: https://issues.apache.org/jira/browse/CALCITE-2073
 Project: Calcite
  Issue Type: Task
  Components: avatica
Reporter: Josh Elser
Assignee: Josh Elser
Priority: Trivial
 Fix For: avatica-1.11.0


The xolstice maven-protobuf-plugin has a runtime dependency on a specific glibc 
version which fails on older OS versions (notably Centos6).

For most builds, it's unnecessary to regenerate the protobuf "specs" into Java 
code. We can add an option for individuals to disable this.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (CALCITE-2072) Allow specification of geospatial functions in connection string

2017-11-30 Thread Michael Mior (JIRA)

Michael Mior created CALCITE-2072:
-

 Summary: Allow specification of geospatial functions in connection 
string
 Key: CALCITE-2072
 URL: https://issues.apache.org/jira/browse/CALCITE-2072
 Project: Calcite
  Issue Type: Bug
  Components: core
Reporter: Michael Mior
Assignee: Julian Hyde


Per Julian's suggestion, it would be good if in addition to {{fun=oracle}}, we 
could allow fun={{spatial}} and also a comma-separated list of possible 
operator tables.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (CALCITE-2009) Possible bug in interpreting ( IN ) OR ( IN ) logic

2017-11-30 Thread Piotr Bojko (JIRA)


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

Piotr Bojko updated CALCITE-2009:
-
Affects Version/s: 1.15.0

> Possible bug in interpreting  ( IN ) OR ( IN ) logic 
> -
>
> Key: CALCITE-2009
> URL: https://issues.apache.org/jira/browse/CALCITE-2009
> Project: Calcite
>  Issue Type: Bug
>Affects Versions: 1.13.0, 1.14.0, 1.15.0
>Reporter: Piotr Bojko
>Assignee: Julian Hyde
> Attachments: logs-when-or-is-used.log, logs-when-union-is-used.log
>
>
> I have schema
> {code:javascript}
> {
>   "version": "1.0",
>   "defaultSchema": "JIRA",
>   "schemas": [
>   {
>   "name": "INTERNAL",
>   "type": "custom",
>   "factory": "%%UNDERLYING_SCHEMA_FACTORY",
>   "operand": {}
>   }, {
>   "name": "JIRA",
>   "type": "custom",
>   "factory": 
> "org.apache.calcite.schema.impl.AbstractSchema$Factory",
>   "operand": {},
>   "tables": [
>   {
>   "name": "ISSUES",
>   "type": "view",
>   "sql": [
>   "SELECT JI.ID, JI.SUMMARY, 
> JI.PROJECT ",
>   "FROM INTERNAL.JIRAISSUE as JI 
> ",
>   "WHERE JI.ID IN (SELECT EAI.ID 
> FROM EXPLICIT_ALLOWED_ISSUES AS EAI) ",
>   "UNION ",
>   "SELECT JI.ID, JI.SUMMARY, 
> JI.PROJECT ",
>   "FROM INTERNAL.JIRAISSUE as JI 
> ",
>   "WHERE JI.PROJECT IN (SELECT 
> AP.ID FROM ALLOWED_PROJECTS AS AP)"
>   ]
>   },
>   {
>   "name": "ALLOWED_PROJECTS",
>   "type": "table",
>   "factory": "%%DELEGATING_TABLE_FACTORY"
>   },
>   {
>   "name": "EXPLICIT_ALLOWED_ISSUES",
>   "type": "table",
>   "factory": "%%DELEGATING_TABLE_FACTORY"
>   }
>   ]
>   } 
>   ]
> }
> {code}
> Where INTERNAL schema points to JDBC native JIRA Schema (through my custom 
> factory, but it only wraps passing datasource instead of user/password/url to 
> db) and JIRA schema has one view and two tables (factories generate java data 
> wrapped in AbstractQueryableTable)
> When running "SELECT * FROM ISSUES" all works. 
> But when changing the view from UNION construction to OR - engine provides no 
> results:
> {code:javascript}
> {
>   "version": "1.0",
>   "defaultSchema": "JIRA",
>   "schemas": [
>   {
>   "name": "INTERNAL",
>   "type": "custom",
>   "factory": "%%UNDERLYING_SCHEMA_FACTORY",
>   "operand": {}
>   }, {
>   "name": "JIRA",
>   "type": "custom",
>   "factory": 
> "org.apache.calcite.schema.impl.AbstractSchema$Factory",
>   "operand": {},
>   "tables": [
>   {
>   "name": "ISSUES",
>   "type": "view",
>   "sql": [
>   "SELECT JI.ID, JI.SUMMARY, 
> JI.PROJECT ",
>   "FROM INTERNAL.JIRAISSUE as JI 
> ",
>   "WHERE JI.ID IN (SELECT EAI.ID 
> FROM EXPLICIT_ALLOWED_ISSUES AS EAI) ",
>   "OR (JI.PROJECT IN (SELECT 
> AP.ID FROM ALLOWED_PROJECTS AS AP))"
>   ]
>   },
>   {
>   "name": "ALLOWED_PROJECTS",
>   "type": "table",
>   "factory": "%%DELEGATING_TABLE_FACTORY"
>   },
>   {
>   "name": "EXPLICIT_ALLOWED_ISSUES",
>   "type": "table",
>

[jira] [Commented] (CALCITE-2009) Possible bug in interpreting ( IN ) OR ( IN ) logic

2017-11-30 Thread Piotr Bojko (JIRA)


[ 
https://issues.apache.org/jira/browse/CALCITE-2009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16272685#comment-16272685
 ] 

Piotr Bojko commented on CALCITE-2009:
--

1.15.0-SNAPSHOT has the same issue.

> Possible bug in interpreting  ( IN ) OR ( IN ) logic 
> -
>
> Key: CALCITE-2009
> URL: https://issues.apache.org/jira/browse/CALCITE-2009
> Project: Calcite
>  Issue Type: Bug
>Affects Versions: 1.13.0, 1.14.0
>Reporter: Piotr Bojko
>Assignee: Julian Hyde
> Attachments: logs-when-or-is-used.log, logs-when-union-is-used.log
>
>
> I have schema
> {code:javascript}
> {
>   "version": "1.0",
>   "defaultSchema": "JIRA",
>   "schemas": [
>   {
>   "name": "INTERNAL",
>   "type": "custom",
>   "factory": "%%UNDERLYING_SCHEMA_FACTORY",
>   "operand": {}
>   }, {
>   "name": "JIRA",
>   "type": "custom",
>   "factory": 
> "org.apache.calcite.schema.impl.AbstractSchema$Factory",
>   "operand": {},
>   "tables": [
>   {
>   "name": "ISSUES",
>   "type": "view",
>   "sql": [
>   "SELECT JI.ID, JI.SUMMARY, 
> JI.PROJECT ",
>   "FROM INTERNAL.JIRAISSUE as JI 
> ",
>   "WHERE JI.ID IN (SELECT EAI.ID 
> FROM EXPLICIT_ALLOWED_ISSUES AS EAI) ",
>   "UNION ",
>   "SELECT JI.ID, JI.SUMMARY, 
> JI.PROJECT ",
>   "FROM INTERNAL.JIRAISSUE as JI 
> ",
>   "WHERE JI.PROJECT IN (SELECT 
> AP.ID FROM ALLOWED_PROJECTS AS AP)"
>   ]
>   },
>   {
>   "name": "ALLOWED_PROJECTS",
>   "type": "table",
>   "factory": "%%DELEGATING_TABLE_FACTORY"
>   },
>   {
>   "name": "EXPLICIT_ALLOWED_ISSUES",
>   "type": "table",
>   "factory": "%%DELEGATING_TABLE_FACTORY"
>   }
>   ]
>   } 
>   ]
> }
> {code}
> Where INTERNAL schema points to JDBC native JIRA Schema (through my custom 
> factory, but it only wraps passing datasource instead of user/password/url to 
> db) and JIRA schema has one view and two tables (factories generate java data 
> wrapped in AbstractQueryableTable)
> When running "SELECT * FROM ISSUES" all works. 
> But when changing the view from UNION construction to OR - engine provides no 
> results:
> {code:javascript}
> {
>   "version": "1.0",
>   "defaultSchema": "JIRA",
>   "schemas": [
>   {
>   "name": "INTERNAL",
>   "type": "custom",
>   "factory": "%%UNDERLYING_SCHEMA_FACTORY",
>   "operand": {}
>   }, {
>   "name": "JIRA",
>   "type": "custom",
>   "factory": 
> "org.apache.calcite.schema.impl.AbstractSchema$Factory",
>   "operand": {},
>   "tables": [
>   {
>   "name": "ISSUES",
>   "type": "view",
>   "sql": [
>   "SELECT JI.ID, JI.SUMMARY, 
> JI.PROJECT ",
>   "FROM INTERNAL.JIRAISSUE as JI 
> ",
>   "WHERE JI.ID IN (SELECT EAI.ID 
> FROM EXPLICIT_ALLOWED_ISSUES AS EAI) ",
>   "OR (JI.PROJECT IN (SELECT 
> AP.ID FROM ALLOWED_PROJECTS AS AP))"
>   ]
>   },
>   {
>   "name": "ALLOWED_PROJECTS",
>   "type": "table",
>   "factory": "%%DELEGATING_TABLE_FACTORY"
>   },
>   {
>   "name": "EXPLICIT_ALLOWED_ISSUES",
>

[jira] [Commented] (CALCITE-2009) Possible bug in interpreting ( IN ) OR ( IN ) logic

2017-11-30 Thread Piotr Bojko (JIRA)


[ 
https://issues.apache.org/jira/browse/CALCITE-2009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16272684#comment-16272684
 ] 

Piotr Bojko commented on CALCITE-2009:
--

I've discovered that when launching the followinf query alone - all works ok:

{code:sql}
SELECT JI.ID, JI.SUMMARY, JI.PROJECT 
FROM INTERNAL.JIRAISSUE as JI 
WHERE JI.ID IN (SELECT EAI.ID FROM EXPLICIT_ALLOWED_ISSUES AS EAI) 
OR (JI.PROJECT IN (SELECT AP.ID FROM ALLOWED_PROJECTS AS AP))
{code}

but if the same query is used as a view - then results are not the same (empty 
results for select * from issues)

{code:javascript}
{
"name": "ISSUES",
"type": "view",
"sql": [
"SELECT JI.ID, JI.SUMMARY, 
JI.PROJECT ",
"FROM INTERNAL.JIRAISSUE as JI 
",
"WHERE JI.ID IN (SELECT EAI.ID 
FROM EXPLICIT_ALLOWED_ISSUES AS EAI) ",
"OR (JI.PROJECT IN (SELECT 
AP.ID FROM ALLOWED_PROJECTS AS AP))"
]
}
{code}


> Possible bug in interpreting  ( IN ) OR ( IN ) logic 
> -
>
> Key: CALCITE-2009
> URL: https://issues.apache.org/jira/browse/CALCITE-2009
> Project: Calcite
>  Issue Type: Bug
>Affects Versions: 1.13.0, 1.14.0
>Reporter: Piotr Bojko
>Assignee: Julian Hyde
> Attachments: logs-when-or-is-used.log, logs-when-union-is-used.log
>
>
> I have schema
> {code:javascript}
> {
>   "version": "1.0",
>   "defaultSchema": "JIRA",
>   "schemas": [
>   {
>   "name": "INTERNAL",
>   "type": "custom",
>   "factory": "%%UNDERLYING_SCHEMA_FACTORY",
>   "operand": {}
>   }, {
>   "name": "JIRA",
>   "type": "custom",
>   "factory": 
> "org.apache.calcite.schema.impl.AbstractSchema$Factory",
>   "operand": {},
>   "tables": [
>   {
>   "name": "ISSUES",
>   "type": "view",
>   "sql": [
>   "SELECT JI.ID, JI.SUMMARY, 
> JI.PROJECT ",
>   "FROM INTERNAL.JIRAISSUE as JI 
> ",
>   "WHERE JI.ID IN (SELECT EAI.ID 
> FROM EXPLICIT_ALLOWED_ISSUES AS EAI) ",
>   "UNION ",
>   "SELECT JI.ID, JI.SUMMARY, 
> JI.PROJECT ",
>   "FROM INTERNAL.JIRAISSUE as JI 
> ",
>   "WHERE JI.PROJECT IN (SELECT 
> AP.ID FROM ALLOWED_PROJECTS AS AP)"
>   ]
>   },
>   {
>   "name": "ALLOWED_PROJECTS",
>   "type": "table",
>   "factory": "%%DELEGATING_TABLE_FACTORY"
>   },
>   {
>   "name": "EXPLICIT_ALLOWED_ISSUES",
>   "type": "table",
>   "factory": "%%DELEGATING_TABLE_FACTORY"
>   }
>   ]
>   } 
>   ]
> }
> {code}
> Where INTERNAL schema points to JDBC native JIRA Schema (through my custom 
> factory, but it only wraps passing datasource instead of user/password/url to 
> db) and JIRA schema has one view and two tables (factories generate java data 
> wrapped in AbstractQueryableTable)
> When running "SELECT * FROM ISSUES" all works. 
> But when changing the view from UNION construction to OR - engine provides no 
> results:
> {code:javascript}
> {
>   "version": "1.0",
>   "defaultSchema": "JIRA",
>   "schemas": [
>   {
>   "name": "INTERNAL",
>   "type": "custom",
>   "factory": "%%UNDERLYING_SCHEMA_FACTORY",
>   "operand": {}
>   }, {
>   "name": "JIRA",
>   "type": "custom",
>   "factory": 
> "org.apache.calcite.schema.impl.AbstractSchema$Factory",
>   "operand": {},
>   "tables": [
>   {
>

[jira] [Commented] (CALCITE-2074) Simplification of AND/OR expressions yields wrong results

[jira] [Created] (CALCITE-2074) Simplification of AND/OR expressions yields wrong results

[jira] [Commented] (CALCITE-2069) RexSimplify.removeNullabilityCast() always removes cast for operand with ANY type

[jira] [Updated] (CALCITE-2069) RexSimplify.removeNullabilityCast() always removes cast for operand with ANY type

[jira] [Commented] (CALCITE-2069) RexSimplify.removeNullabilityCast() always removes cast for operand with ANY type

[jira] [Commented] (CALCITE-2072) Allow specification of geospatial functions in connection string

[jira] [Resolved] (CALCITE-2073) Allow disabling of protobuf generation

[jira] [Commented] (CALCITE-2073) Allow disabling of protobuf generation

[jira] [Commented] (CALCITE-2073) Allow disabling of protobuf generation

[jira] [Created] (CALCITE-2073) Allow disabling of protobuf generation

[jira] [Created] (CALCITE-2072) Allow specification of geospatial functions in connection string

[jira] [Updated] (CALCITE-2009) Possible bug in interpreting ( IN ) OR ( IN ) logic

[jira] [Commented] (CALCITE-2009) Possible bug in interpreting ( IN ) OR ( IN ) logic

[jira] [Commented] (CALCITE-2009) Possible bug in interpreting ( IN ) OR ( IN ) logic

14 matches

Site Navigation

Mail list logo

Footer information