[jira] [Updated] (CALCITE-2791) Add the JSON_TYPE function
[ https://issues.apache.org/jira/browse/CALCITE-2791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] xuqianjin updated CALCITE-2791: --- Labels: https://github.com/apache/calcite/pull/1013 (was: ) > Add the JSON_TYPE function > -- > > Key: CALCITE-2791 > URL: https://issues.apache.org/jira/browse/CALCITE-2791 > Project: Calcite > Issue Type: Improvement >Reporter: xuqianjin >Assignee: Julian Hyde >Priority: Major > Labels: https://github.com/apache/calcite/pull/1013 > > The data in json can be =, <, <=, >, >=, <>,! =, and <=>. But the data types > in json can be diverse, so when you compare different types, you have a > priority, and the high priority is greater than the low priority (you can > view the types with the JSON_TYPE() function). The priorities are as follows: > BOOLEAN > ARRAY > OBJECT > STRING > INTEGER > LONG > DOUBLE > NULL -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2791) Add the JSON_TYPE function
[ https://issues.apache.org/jira/browse/CALCITE-2791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] xuqianjin updated CALCITE-2791: --- Component/s: core > Add the JSON_TYPE function > -- > > Key: CALCITE-2791 > URL: https://issues.apache.org/jira/browse/CALCITE-2791 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: xuqianjin >Assignee: Julian Hyde >Priority: Major > Labels: https://github.com/apache/calcite/pull/1013 > > The data in json can be =, <, <=, >, >=, <>,! =, and <=>. But the data types > in json can be diverse, so when you compare different types, you have a > priority, and the high priority is greater than the low priority (you can > view the types with the JSON_TYPE() function). The priorities are as follows: > BOOLEAN > ARRAY > OBJECT > STRING > INTEGER > LONG > DOUBLE > NULL -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2721) Support parsing of DOT + MEMBER_FUNCTION
[
https://issues.apache.org/jira/browse/CALCITE-2721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16752829#comment-16752829
]
Rong Rong commented on CALCITE-2721:
Fixed the issues and create this
[PR|https://github.com/apache/calcite/pull/1011]. Please kindly take a look
> Support parsing of DOT + MEMBER_FUNCTION
>
>
> Key: CALCITE-2721
> URL: https://issues.apache.org/jira/browse/CALCITE-2721
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Rong Rong
>Assignee: Julian Hyde
>Priority: Major
> Attachments: 6_17_Method_invocation.png
>
>
> Support parsing of + parsing Similar to
> {panel:title=Example}
> {{SELECT t.complex_col}}*{{.member_func()}}* {{FROM tbl;}}
> {panel}
> For more details please see: [Member
> Function|https://docs.oracle.com/cd/B19306_01/server.102/b14200/statements_8001.htm#i2126584]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2804) Cast does not work in Druid when casting to timestamp
[
https://issues.apache.org/jira/browse/CALCITE-2804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16752784#comment-16752784
]
Justin Szeluga commented on CALCITE-2804:
-
I added a unit test to the pull request. I can't get the test VM to work right
but I put a breakpoint right before it issues the query and I can see the JSON
there. With my fix it is correct so it should fail without my fix
> Cast does not work in Druid when casting to timestamp
> -
>
> Key: CALCITE-2804
> URL: https://issues.apache.org/jira/browse/CALCITE-2804
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.18.0
>Reporter: Justin Szeluga
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.19.0
>
>
> When trying to execute a simple statement of
> {code:java}
> select cast("__time" as timestamp) from my_datasource limit 10;{code}
> the query fails with a 500 error
>
> {code:java}
> Caused by: java.io.IOException: Server returned HTTP response code: 500 for
> URL: http://localhost:58082/druid/v2/?pretty
> at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(Unknown Source)
> at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
> at org.apache.calcite.runtime.HttpUtils.executeMethod(HttpUtils.java:137)
> at org.apache.calcite.runtime.HttpUtils.post(HttpUtils.java:110)
> at
> org.apache.calcite.adapter.druid.DruidConnectionImpl.request(DruidConnectionImpl.java:109)
> ... 29 more
> {code}
> because the JSON generated is incorrect. Here is the generated JSON
>
>
> {code:java}
> {
> "queryType": "scan",
> "dataSource": "my_datasource",
> "intervals": [
> "1900-01-01T00:00:00.000Z/3000-01-01T00:00:00.000Z"
> ],
> "virtualColumns": [
> {
> "type": "expression",
> "name": "vc",
> "expression":
> "timestamp_parse(timestamp_format(\"__time\",'-MM-dd\\u0027T\\u0027HH:mm:ss.SSS\\u0027Z\\u0027','America/New_York'),'','UTC')",
> "outputType": "LONG"
> }
> ],
> "columns": [
> "vc"
> ],
> "resultFormat": "compactedList",
> "limit": 10
> }
> {code}
> There are two problems. First, the "__time" dimension is not formatted
> correctly in timestamp_format. The escaped quotes need to be removed.
> Also, the call to timestamp_parse is incorrect. If a timezone is going to be
> provided then a date time format needs to be provided as well. Currently, it
> is only empty string
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CALCITE-2807) Identify expanded IS NOT DISTINCT FROM expression when pushing down filter past join
Laurent Goujon created CALCITE-2807: --- Summary: Identify expanded IS NOT DISTINCT FROM expression when pushing down filter past join Key: CALCITE-2807 URL: https://issues.apache.org/jira/browse/CALCITE-2807 Project: Calcite Issue Type: Improvement Components: core Reporter: Laurent Goujon Assignee: Julian Hyde IS NOT DISTINCT FROM expressions in join condition might actually be considered as equi-join conditions, and RelOptUtil#splitJoinConditions() has support for it. But some other join related functions/rules don't. One of them is RelOptUtil#pushDownJoinConditions (used by JoinPushExpressionsRule) which tries to push filter expressions below the join, but ends up modifying the join expression in a way which makes identify an IDNF condition impossible later. For example expression OR(AND(IS_NULL($1), IS_NULL($4)), EQUALS($1,$4)) will be changed into OR(AND($3, $6), EQUALS($1, $5)) which makes it harder/impossible for RelOptUtil#splitJoinConditions() to identify an IS NOT DISTINCT FROM equi-join condition. This is a variant of CALCITE-2803 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2223) ProjectMergeRule is infinitely matched when is applied after ProjectReduceExpressionsRule
[
https://issues.apache.org/jira/browse/CALCITE-2223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16752746#comment-16752746
]
Vladimir Sitnikov commented on CALCITE-2223:
It seems the change improves execution time for certain tests.
It would be interesting to hear if this change introduces a noticeable
degradation in plan quality/duration.
For instance: org.apache.calcite.test.JdbcTest#testJoinManyWay takes improves
7sec -> 3.5sec.
Note: checkJoinNWay(7) takes 30 seconds before the fix, and with the fix it
takes 6-8.
checkJoinNWay(8) seems to spin forever without the fix, and with the fix it
takes 6-8.
Travis tests improve from
[1h30m|https://travis-ci.org/apache/calcite/builds/484533821] to
[1h22m|https://travis-ci.org/apache/calcite/builds/484543102].
> ProjectMergeRule is infinitely matched when is applied after
> ProjectReduceExpressionsRule
> -
>
> Key: CALCITE-2223
> URL: https://issues.apache.org/jira/browse/CALCITE-2223
> Project: Calcite
> Issue Type: Bug
>Reporter: Volodymyr Vysotskyi
>Assignee: Julian Hyde
>Priority: Critical
> Attachments: heap_overview.png, provenance_contents.png
>
>
> For queries like this:
> {code:sql}
> select t1.f from (select cast(f as int) f, f from (select cast(f as int) f
> from (values('1')) t(f))) as t1
> {code}
> OOM is thrown when {{ProjectMergeRule}} is applied before applying
> {{ProjectReduceExpressionsRule}} in VolcanoPlanner.
> A simple test to reproduce this issue (in {{RelOptRulesTest}}):
> {code:java}
> @Test public void testOomProjectMergeRule() {
> RelBuilder relBuilder =
> RelBuilder.create(RelBuilderTest.config().build());
> RelNode relNode = relBuilder
> .values(new String[]{"f"}, "1")
> .project(
> relBuilder.alias(
> relBuilder.cast(relBuilder.field(0), SqlTypeName.INTEGER),
> "f"))
> .project(
> relBuilder.alias(
> relBuilder.cast(relBuilder.field(0), SqlTypeName.INTEGER),
> "f0"),
> relBuilder.alias(relBuilder.field(0), "f"))
> .project(
> relBuilder.alias(relBuilder.field(0), "f"))
> .build();
> RelOptPlanner planner = relNode.getCluster().getPlanner();
> RuleSet ruleSet =
> RuleSets.ofList(
> ReduceExpressionsRule.PROJECT_INSTANCE,
> new ProjectMergeRuleWithLongerName(),
> EnumerableRules.ENUMERABLE_PROJECT_RULE,
> EnumerableRules.ENUMERABLE_VALUES_RULE);
> Program program = Programs.of(ruleSet);
> RelTraitSet toTraits =
> relNode.getCluster().traitSet()
> .replace(0, EnumerableConvention.INSTANCE);
> RelNode output = program.run(planner, relNode, toTraits,
> ImmutableList.of(),
> ImmutableList.of());
> // check for output
> }
> /**
>* ProjectMergeRule inheritor which has
>* class name greater than ProjectReduceExpressionsRule class name
> (String.compareTo()).
>*
>* It is needed for RuleQueue.popMatch() method
>* to apply this rule before ProjectReduceExpressionsRule.
>*/
> private static class ProjectMergeRuleWithLongerName extends
> ProjectMergeRule {
> public ProjectMergeRuleWithLongerName() {
> super(true, RelFactories.LOGICAL_BUILDER);
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2223) ProjectMergeRule is infinitely matched when is applied after ProjectReduceExpressionsRule
[
https://issues.apache.org/jira/browse/CALCITE-2223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16752746#comment-16752746
]
Vladimir Sitnikov edited comment on CALCITE-2223 at 1/25/19 10:18 PM:
--
It seems the change improves execution time for certain tests.
It would be interesting to hear if this change introduces a noticeable
degradation in plan quality/duration.
For instance: org.apache.calcite.test.JdbcTest#testJoinManyWay improves 7sec ->
3.5sec.
Note: checkJoinNWay(7) takes 30 seconds before the fix, and with the fix it
takes 6-8.
checkJoinNWay(8) seems to spin forever without the fix, and with the fix it
takes 6-8.
Travis tests improve from
[1h30m|https://travis-ci.org/apache/calcite/builds/484533821] to
[1h22m|https://travis-ci.org/apache/calcite/builds/484543102].
was (Author: vladimirsitnikov):
It seems the change improves execution time for certain tests.
It would be interesting to hear if this change introduces a noticeable
degradation in plan quality/duration.
For instance: org.apache.calcite.test.JdbcTest#testJoinManyWay takes improves
7sec -> 3.5sec.
Note: checkJoinNWay(7) takes 30 seconds before the fix, and with the fix it
takes 6-8.
checkJoinNWay(8) seems to spin forever without the fix, and with the fix it
takes 6-8.
Travis tests improve from
[1h30m|https://travis-ci.org/apache/calcite/builds/484533821] to
[1h22m|https://travis-ci.org/apache/calcite/builds/484543102].
> ProjectMergeRule is infinitely matched when is applied after
> ProjectReduceExpressionsRule
> -
>
> Key: CALCITE-2223
> URL: https://issues.apache.org/jira/browse/CALCITE-2223
> Project: Calcite
> Issue Type: Bug
>Reporter: Volodymyr Vysotskyi
>Assignee: Julian Hyde
>Priority: Critical
> Attachments: heap_overview.png, provenance_contents.png
>
>
> For queries like this:
> {code:sql}
> select t1.f from (select cast(f as int) f, f from (select cast(f as int) f
> from (values('1')) t(f))) as t1
> {code}
> OOM is thrown when {{ProjectMergeRule}} is applied before applying
> {{ProjectReduceExpressionsRule}} in VolcanoPlanner.
> A simple test to reproduce this issue (in {{RelOptRulesTest}}):
> {code:java}
> @Test public void testOomProjectMergeRule() {
> RelBuilder relBuilder =
> RelBuilder.create(RelBuilderTest.config().build());
> RelNode relNode = relBuilder
> .values(new String[]{"f"}, "1")
> .project(
> relBuilder.alias(
> relBuilder.cast(relBuilder.field(0), SqlTypeName.INTEGER),
> "f"))
> .project(
> relBuilder.alias(
> relBuilder.cast(relBuilder.field(0), SqlTypeName.INTEGER),
> "f0"),
> relBuilder.alias(relBuilder.field(0), "f"))
> .project(
> relBuilder.alias(relBuilder.field(0), "f"))
> .build();
> RelOptPlanner planner = relNode.getCluster().getPlanner();
> RuleSet ruleSet =
> RuleSets.ofList(
> ReduceExpressionsRule.PROJECT_INSTANCE,
> new ProjectMergeRuleWithLongerName(),
> EnumerableRules.ENUMERABLE_PROJECT_RULE,
> EnumerableRules.ENUMERABLE_VALUES_RULE);
> Program program = Programs.of(ruleSet);
> RelTraitSet toTraits =
> relNode.getCluster().traitSet()
> .replace(0, EnumerableConvention.INSTANCE);
> RelNode output = program.run(planner, relNode, toTraits,
> ImmutableList.of(),
> ImmutableList.of());
> // check for output
> }
> /**
>* ProjectMergeRule inheritor which has
>* class name greater than ProjectReduceExpressionsRule class name
> (String.compareTo()).
>*
>* It is needed for RuleQueue.popMatch() method
>* to apply this rule before ProjectReduceExpressionsRule.
>*/
> private static class ProjectMergeRuleWithLongerName extends
> ProjectMergeRule {
> public ProjectMergeRuleWithLongerName() {
> super(true, RelFactories.LOGICAL_BUILDER);
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2802) Druid adapter: Usage of range conditions like "2010-01-01 < timestamp" leads to incorrect results
[
https://issues.apache.org/jira/browse/CALCITE-2802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16752735#comment-16752735
]
Jesus Camacho Rodriguez commented on CALCITE-2802:
--
PR looks good to me. Thanks [~kgyrtkirk]
> Druid adapter: Usage of range conditions like "2010-01-01 < timestamp" leads
> to incorrect results
> -
>
> Key: CALCITE-2802
> URL: https://issues.apache.org/jira/browse/CALCITE-2802
> Project: Calcite
> Issue Type: Bug
>Reporter: Zoltan Haindrich
>Assignee: Zoltan Haindrich
>Priority: Major
>
> Timestamp range conditions when the timestamp is on left hand side work
> correctly; however when the literal is on the left hand side results are
> missing.
> {code}
> @Test
> public void testRangeCalc() {
> final Fixture2 f = new Fixture2();
> checkDateRange(f,
> f.and(
> f.le(f.timestampLiteral(2011, Calendar.JANUARY, 1), f.t),
> f.le(f.t, f.timestampLiteral(2012, Calendar.FEBRUARY, 2))),
> is("[2011-01-01T00:00:00.000Z/2012-02-02T00:00:00.001Z]"));
> }
> {code}
> Fail:
> {code}
> java.lang.AssertionError:
> Expected: is "[2011-01-01T00:00:00.000Z/2012-02-02T00:00:00.001Z]"
> but: was "[1900-01-01T00:00:00.000Z/2011-01-01T00:00:00.001Z]"
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2804) Cast does not work in Druid when casting to timestamp
[
https://issues.apache.org/jira/browse/CALCITE-2804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16752725#comment-16752725
]
Stamatis Zampetakis commented on CALCITE-2804:
--
Hi [~jszeluga], can you please include a unit test which fails without the PR?
> Cast does not work in Druid when casting to timestamp
> -
>
> Key: CALCITE-2804
> URL: https://issues.apache.org/jira/browse/CALCITE-2804
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.18.0
>Reporter: Justin Szeluga
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.19.0
>
>
> When trying to execute a simple statement of
> {code:java}
> select cast("__time" as timestamp) from my_datasource limit 10;{code}
> the query fails with a 500 error
>
> {code:java}
> Caused by: java.io.IOException: Server returned HTTP response code: 500 for
> URL: http://localhost:58082/druid/v2/?pretty
> at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(Unknown Source)
> at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
> at org.apache.calcite.runtime.HttpUtils.executeMethod(HttpUtils.java:137)
> at org.apache.calcite.runtime.HttpUtils.post(HttpUtils.java:110)
> at
> org.apache.calcite.adapter.druid.DruidConnectionImpl.request(DruidConnectionImpl.java:109)
> ... 29 more
> {code}
> because the JSON generated is incorrect. Here is the generated JSON
>
>
> {code:java}
> {
> "queryType": "scan",
> "dataSource": "my_datasource",
> "intervals": [
> "1900-01-01T00:00:00.000Z/3000-01-01T00:00:00.000Z"
> ],
> "virtualColumns": [
> {
> "type": "expression",
> "name": "vc",
> "expression":
> "timestamp_parse(timestamp_format(\"__time\",'-MM-dd\\u0027T\\u0027HH:mm:ss.SSS\\u0027Z\\u0027','America/New_York'),'','UTC')",
> "outputType": "LONG"
> }
> ],
> "columns": [
> "vc"
> ],
> "resultFormat": "compactedList",
> "limit": 10
> }
> {code}
> There are two problems. First, the "__time" dimension is not formatted
> correctly in timestamp_format. The escaped quotes need to be removed.
> Also, the call to timestamp_parse is incorrect. If a timezone is going to be
> provided then a date time format needs to be provided as well. Currently, it
> is only empty string
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2734) MongoDB adapter tutorial is out of date
[ https://issues.apache.org/jira/browse/CALCITE-2734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16752683#comment-16752683 ] Andrei Sereda commented on CALCITE-2734: # Was fixed by [e80ec9|https://github.com/apache/calcite/commit/e80ec9750a0963345444b5614f4cfc5fd4c0da75] # Data source files are part of [foodmart-data-json|https://github.com/julianhyde/foodmart-data-json] distribution. During tests they're loaded from jar files. Can you import them separately ? # Fixed by [b43a314b60|https://github.com/apache/calcite/commit/b43a314b60f42d1e58febc39c04cbbbefc3503e1] . Pls test and confirm. > MongoDB adapter tutorial is out of date > --- > > Key: CALCITE-2734 > URL: https://issues.apache.org/jira/browse/CALCITE-2734 > Project: Calcite > Issue Type: Improvement > Components: avatica, mongodb >Affects Versions: 1.17.0 > Environment: Host: Mac OS 10.14.1 > Calcite: Master >Reporter: TommyLike >Priority: Major > Labels: document > > Hey all, > I am trying to learn Calcite via MongoDB adapter, and I found there is a > related tutorial section in > [HOWTO|[https://calcite.apache.org/docs/howto.html#mongodb-adapter]|https://calcite.apache.org/docs/howto.html#mongodb-adapter],]. > But it seems to be a little out of date now, I found several issues at > least: > 1. model file: *mongo-zips-model.json* has been renamed into > *mongo-models.json.* > 2. data source file *zips.json* doesn't include all the data required in the > models.json file. > 3. the MongoDB adapter can not be directly used, because there is a log > related bug when execute command ``!connect > jdbc:calcite:model=mongodb/target/test-classes/mongo-model.json admin > admin``, related output: > ``` > SLF4J: Detected both log4j-over-slf4j.jar AND slf4j-log4j12.jar on the class > path, preempting StackOverflowError. > SLF4J: See also [http://www.slf4j.org/codes.html#log4jDelegationLoop] for > more details. > Caused by: java.lang.NoClassDefFoundError: Could not initialize class > org.apache.log4j.Log4jLoggerFactory > ``` > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CALCITE-2806) Cassandra adapter doesn't allow uppercase characters in table names
[ https://issues.apache.org/jira/browse/CALCITE-2806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Mior resolved CALCITE-2806. --- Resolution: Fixed Fixed in [edbaf6c|https://github.com/apache/calcite/commit/edbaf6c2b61d10eed082ca33993b919b683fd955]. > Cassandra adapter doesn't allow uppercase characters in table names > --- > > Key: CALCITE-2806 > URL: https://issues.apache.org/jira/browse/CALCITE-2806 > Project: Calcite > Issue Type: Bug > Components: cassandra >Reporter: Michael Mior >Assignee: Michael Mior >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-2806) Cassandra adapter doesn't allow uppercase characters in table names
Michael Mior created CALCITE-2806: - Summary: Cassandra adapter doesn't allow uppercase characters in table names Key: CALCITE-2806 URL: https://issues.apache.org/jira/browse/CALCITE-2806 Project: Calcite Issue Type: Bug Components: cassandra Reporter: Michael Mior Assignee: Michael Mior -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CALCITE-2805) Can't specify port with Cassandra adapter in connection string
[ https://issues.apache.org/jira/browse/CALCITE-2805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Mior resolved CALCITE-2805. --- Resolution: Fixed > Can't specify port with Cassandra adapter in connection string > -- > > Key: CALCITE-2805 > URL: https://issues.apache.org/jira/browse/CALCITE-2805 > Project: Calcite > Issue Type: Bug > Components: cassandra >Affects Versions: 1.18.0 >Reporter: Michael Mior >Assignee: Michael Mior >Priority: Major > Fix For: 1.19.0 > > > Since the Cassandra adapter currently expects the port to be numeric (which > it is when parsed from JSON) it fails when specifying the port in the > connection string since all values are represented as strings. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2805) Can't specify port with Cassandra adapter in connection string
[ https://issues.apache.org/jira/browse/CALCITE-2805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16752653#comment-16752653 ] Michael Mior commented on CALCITE-2805: --- Fixed in [cd01913c2|https://github.com/apache/calcite/commit/cd01913c2c2333ea120b3b5dedcdacf40c618de4]. > Can't specify port with Cassandra adapter in connection string > -- > > Key: CALCITE-2805 > URL: https://issues.apache.org/jira/browse/CALCITE-2805 > Project: Calcite > Issue Type: Bug > Components: cassandra >Affects Versions: 1.18.0 >Reporter: Michael Mior >Assignee: Michael Mior >Priority: Major > Fix For: 1.19.0 > > > Since the Cassandra adapter currently expects the port to be numeric (which > it is when parsed from JSON) it fails when specifying the port in the > connection string since all values are represented as strings. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-2805) Can't specify port with Cassandra adapter in connection string
Michael Mior created CALCITE-2805: - Summary: Can't specify port with Cassandra adapter in connection string Key: CALCITE-2805 URL: https://issues.apache.org/jira/browse/CALCITE-2805 Project: Calcite Issue Type: Bug Components: cassandra Affects Versions: 1.18.0 Reporter: Michael Mior Assignee: Michael Mior Fix For: 1.19.0 Since the Cassandra adapter currently expects the port to be numeric (which it is when parsed from JSON) it fails when specifying the port in the connection string since all values are represented as strings. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2804) Cast does not work in Druid when casting to timestamp
[
https://issues.apache.org/jira/browse/CALCITE-2804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16752616#comment-16752616
]
Justin Szeluga commented on CALCITE-2804:
-
Pull request https://github.com/apache/calcite/pull/1014
> Cast does not work in Druid when casting to timestamp
> -
>
> Key: CALCITE-2804
> URL: https://issues.apache.org/jira/browse/CALCITE-2804
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.18.0
>Reporter: Justin Szeluga
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.19.0
>
>
> When trying to execute a simple statement of
> {code:java}
> select cast("__time" as timestamp) from my_datasource limit 10;{code}
> the query fails with a 500 error
>
> {code:java}
> Caused by: java.io.IOException: Server returned HTTP response code: 500 for
> URL: http://localhost:58082/druid/v2/?pretty
> at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(Unknown Source)
> at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
> at org.apache.calcite.runtime.HttpUtils.executeMethod(HttpUtils.java:137)
> at org.apache.calcite.runtime.HttpUtils.post(HttpUtils.java:110)
> at
> org.apache.calcite.adapter.druid.DruidConnectionImpl.request(DruidConnectionImpl.java:109)
> ... 29 more
> {code}
> because the JSON generated is incorrect. Here is the generated JSON
>
>
> {code:java}
> {
> "queryType": "scan",
> "dataSource": "my_datasource",
> "intervals": [
> "1900-01-01T00:00:00.000Z/3000-01-01T00:00:00.000Z"
> ],
> "virtualColumns": [
> {
> "type": "expression",
> "name": "vc",
> "expression":
> "timestamp_parse(timestamp_format(\"__time\",'-MM-dd\\u0027T\\u0027HH:mm:ss.SSS\\u0027Z\\u0027','America/New_York'),'','UTC')",
> "outputType": "LONG"
> }
> ],
> "columns": [
> "vc"
> ],
> "resultFormat": "compactedList",
> "limit": 10
> }
> {code}
> There are two problems. First, the "__time" dimension is not formatted
> correctly in timestamp_format. The escaped quotes need to be removed.
> Also, the call to timestamp_parse is incorrect. If a timezone is going to be
> provided then a date time format needs to be provided as well. Currently, it
> is only empty string
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CALCITE-2804) Cast does not work in Druid when casting to timestamp
Justin Szeluga created CALCITE-2804:
---
Summary: Cast does not work in Druid when casting to timestamp
Key: CALCITE-2804
URL: https://issues.apache.org/jira/browse/CALCITE-2804
Project: Calcite
Issue Type: Bug
Affects Versions: 1.18.0
Reporter: Justin Szeluga
Assignee: Julian Hyde
Fix For: 1.19.0
When trying to execute a simple statement of
{code:java}
select cast("__time" as timestamp) from my_datasource limit 10;{code}
the query fails with a 500 error
{code:java}
Caused by: java.io.IOException: Server returned HTTP response code: 500 for
URL: http://localhost:58082/druid/v2/?pretty
at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
at org.apache.calcite.runtime.HttpUtils.executeMethod(HttpUtils.java:137)
at org.apache.calcite.runtime.HttpUtils.post(HttpUtils.java:110)
at
org.apache.calcite.adapter.druid.DruidConnectionImpl.request(DruidConnectionImpl.java:109)
... 29 more
{code}
because the JSON generated is incorrect. Here is the generated JSON
{code:java}
{
"queryType": "scan",
"dataSource": "my_datasource",
"intervals": [
"1900-01-01T00:00:00.000Z/3000-01-01T00:00:00.000Z"
],
"virtualColumns": [
{
"type": "expression",
"name": "vc",
"expression":
"timestamp_parse(timestamp_format(\"__time\",'-MM-dd\\u0027T\\u0027HH:mm:ss.SSS\\u0027Z\\u0027','America/New_York'),'','UTC')",
"outputType": "LONG"
}
],
"columns": [
"vc"
],
"resultFormat": "compactedList",
"limit": 10
}
{code}
There are two problems. First, the "__time" dimension is not formatted
correctly in timestamp_format. The escaped quotes need to be removed.
Also, the call to timestamp_parse is incorrect. If a timezone is going to be
provided then a date time format needs to be provided as well. Currently, it is
only empty string
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2223) ProjectMergeRule is infinitely matched when is applied after ProjectReduceExpressionsRule
[
https://issues.apache.org/jira/browse/CALCITE-2223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16752596#comment-16752596
]
Vladimir Sitnikov commented on CALCITE-2223:
Just in case I've implemented a naive approach to check if every added RelNode
creates a cycle or not.
If a cycle is detected, the added RelNode is ignored by the rules.
I've updated https://github.com/apache/calcite/pull/855 with the new approach
(there's https://github.com/vlsi/calcite/tree/CALCITE-2223-18 just in case)
It still passes all the existing Calcite tests, and it does solve
[~vvysotskyi]'s {{TestProjectWithFunctions.testCastFunctions}}
[~vvysotskyi], do you have extra options/cases to test the fix?
> ProjectMergeRule is infinitely matched when is applied after
> ProjectReduceExpressionsRule
> -
>
> Key: CALCITE-2223
> URL: https://issues.apache.org/jira/browse/CALCITE-2223
> Project: Calcite
> Issue Type: Bug
>Reporter: Volodymyr Vysotskyi
>Assignee: Julian Hyde
>Priority: Critical
> Attachments: heap_overview.png, provenance_contents.png
>
>
> For queries like this:
> {code:sql}
> select t1.f from (select cast(f as int) f, f from (select cast(f as int) f
> from (values('1')) t(f))) as t1
> {code}
> OOM is thrown when {{ProjectMergeRule}} is applied before applying
> {{ProjectReduceExpressionsRule}} in VolcanoPlanner.
> A simple test to reproduce this issue (in {{RelOptRulesTest}}):
> {code:java}
> @Test public void testOomProjectMergeRule() {
> RelBuilder relBuilder =
> RelBuilder.create(RelBuilderTest.config().build());
> RelNode relNode = relBuilder
> .values(new String[]{"f"}, "1")
> .project(
> relBuilder.alias(
> relBuilder.cast(relBuilder.field(0), SqlTypeName.INTEGER),
> "f"))
> .project(
> relBuilder.alias(
> relBuilder.cast(relBuilder.field(0), SqlTypeName.INTEGER),
> "f0"),
> relBuilder.alias(relBuilder.field(0), "f"))
> .project(
> relBuilder.alias(relBuilder.field(0), "f"))
> .build();
> RelOptPlanner planner = relNode.getCluster().getPlanner();
> RuleSet ruleSet =
> RuleSets.ofList(
> ReduceExpressionsRule.PROJECT_INSTANCE,
> new ProjectMergeRuleWithLongerName(),
> EnumerableRules.ENUMERABLE_PROJECT_RULE,
> EnumerableRules.ENUMERABLE_VALUES_RULE);
> Program program = Programs.of(ruleSet);
> RelTraitSet toTraits =
> relNode.getCluster().traitSet()
> .replace(0, EnumerableConvention.INSTANCE);
> RelNode output = program.run(planner, relNode, toTraits,
> ImmutableList.of(),
> ImmutableList.of());
> // check for output
> }
> /**
>* ProjectMergeRule inheritor which has
>* class name greater than ProjectReduceExpressionsRule class name
> (String.compareTo()).
>*
>* It is needed for RuleQueue.popMatch() method
>* to apply this rule before ProjectReduceExpressionsRule.
>*/
> private static class ProjectMergeRuleWithLongerName extends
> ProjectMergeRule {
> public ProjectMergeRuleWithLongerName() {
> super(true, RelFactories.LOGICAL_BUILDER);
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2803) Identify expanded IS NOT DISTINCT FROM expression when pushing project past join
[
https://issues.apache.org/jira/browse/CALCITE-2803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16752591#comment-16752591
]
Laurent Goujon commented on CALCITE-2803:
-
One possible solution is to normalize the join condition just before using
{{PushProjector}} so that the expanded {{IS NOT DISTINCT FROM}} expressions are
converted back into the collapsed version, and so doesn't cause extra
expressions to be created.
Another solution is not to modify filter condition since this is also managed
by {{JoinPushExpressionsRule}} anyway.
> Identify expanded IS NOT DISTINCT FROM expression when pushing project past
> join
>
>
> Key: CALCITE-2803
> URL: https://issues.apache.org/jira/browse/CALCITE-2803
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Laurent Goujon
>Assignee: Julian Hyde
>Priority: Major
>
> {{IS NOT DISTINCT FROM}} expressions in join condition might actually be
> considered as equi-join conditions, and {{RelOptUtil#splitJoinConditions()}}
> has support for it. But some other join related functions/rules don't.
> One of them is {{ProjectJoinTransposeRule}} which tries to push project
> expressions below the join, but ends up modifying the join expression too by
> pushing complex expression below.
> For example expression {{OR(AND(IS_NULL($1), IS_NULL($4)), EQUALS($1,$4))}}
> will be changed into {{OR(AND($3, $6), EQUALS($1, $5))}} which makes it
> harder/impossible for {{RelOptUtil#splitJoinConditions()}} to identify an
> {{IS NOT DISTINCT FROM}} equi-join condition.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2803) Identify expanded IS NOT DISTINCT FROM expression when pushing project past join
[
https://issues.apache.org/jira/browse/CALCITE-2803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Laurent Goujon updated CALCITE-2803:
Description:
{{IS NOT DISTINCT FROM}} expressions in join condition might actually be
considered as equi-join conditions, and {{RelOptUtil#splitJoinConditions()}}
has support for it. But some other join related functions/rules don't.
One of them is {{ProjectJoinTransposeRule}} which tries to push project
expressions below the join, but ends up modifying the join expression too by
pushing complex expression below.
For example expression {{OR(AND(IS_NULL($1), IS_NULL($4)), EQUALS($1,$4))}}
will be changed into {{OR(AND($3, $6), EQUALS($1, $5))}} which makes it
harder/impossible for {{RelOptUtil#splitJoinConditions()}} to identify an {{IS
NOT DISTINCT FROM}} equi-join condition.
was:
{{IS NOT DISTINCT FROM}} expressions in join condition might actually be
considered as equi-join conditions, and {{RelOptUtil#splitJoinConditions()}}
has support for it. But some other join related functions/rules don't.
One of them is {{ProjectJoinTransposeRule}} which tries to push project
expressions below the join, but ends up modifying the join expression too by
pushing complex expression below/
For example expression {{OR(AND(IS_NULL($1), IS_NULL($4)), EQUALS($1,$4))}}
will be changed into {{OR(AND($3, $6), EQUALS($1, $5))}} which makes it
harder/impossible for {{RelOptUtil#splitJoinConditions()}} to identify an {{IS
NOT DISTINCT FROM}} equi-join condition.
> Identify expanded IS NOT DISTINCT FROM expression when pushing project past
> join
>
>
> Key: CALCITE-2803
> URL: https://issues.apache.org/jira/browse/CALCITE-2803
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Laurent Goujon
>Assignee: Julian Hyde
>Priority: Major
>
> {{IS NOT DISTINCT FROM}} expressions in join condition might actually be
> considered as equi-join conditions, and {{RelOptUtil#splitJoinConditions()}}
> has support for it. But some other join related functions/rules don't.
> One of them is {{ProjectJoinTransposeRule}} which tries to push project
> expressions below the join, but ends up modifying the join expression too by
> pushing complex expression below.
> For example expression {{OR(AND(IS_NULL($1), IS_NULL($4)), EQUALS($1,$4))}}
> will be changed into {{OR(AND($3, $6), EQUALS($1, $5))}} which makes it
> harder/impossible for {{RelOptUtil#splitJoinConditions()}} to identify an
> {{IS NOT DISTINCT FROM}} equi-join condition.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CALCITE-2803) Identify expanded IS NOT DISTINCT FROM expression when pushing project past join
Laurent Goujon created CALCITE-2803:
---
Summary: Identify expanded IS NOT DISTINCT FROM expression when
pushing project past join
Key: CALCITE-2803
URL: https://issues.apache.org/jira/browse/CALCITE-2803
Project: Calcite
Issue Type: Improvement
Components: core
Reporter: Laurent Goujon
Assignee: Julian Hyde
{{IS NOT DISTINCT FROM}} expressions in join condition might actually be
considered as equi-join conditions, and {{RelOptUtil#splitJoinConditions()}}
has support for it. But some other join related functions/rules don't.
One of them is {{ProjectJoinTransposeRule}} which tries to push project
expressions below the join, but ends up modifying the join expression too by
pushing complex expression below/
For example expression {{OR(AND(IS_NULL($1), IS_NULL($4)), EQUALS($1,$4))}}
will be changed into {{OR(AND($3, $6), EQUALS($1, $5))}} which makes it
harder/impossible for {{RelOptUtil#splitJoinConditions()}} to identify an {{IS
NOT DISTINCT FROM}} equi-join condition.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2801) Check input type in AggregateUnionAggregateRule when remove the bottom Aggregate
[
https://issues.apache.org/jira/browse/CALCITE-2801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16752569#comment-16752569
]
Julian Hyde commented on CALCITE-2801:
--
I believe RelBuilder.convert will do nothing if the input types are already the
same. (If it doesn't, it should.)
> Check input type in AggregateUnionAggregateRule when remove the bottom
> Aggregate
>
>
> Key: CALCITE-2801
> URL: https://issues.apache.org/jira/browse/CALCITE-2801
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Hequn Cheng
>Assignee: Hequn Cheng
>Priority: Major
>
> In {{AggregateUnionAggregateRule}}, we may remove the bottom Aggregate and
> use it's input as the new input of Union directly. However, the bottom
> Aggregate and it's input may not share the same row type. As Union requires
> all inputs with a same row type, once we remove the bottom Aggregate, an
> exception will be thrown.
> The exception can be reproduced by the following test:
> {code:java}
> @Test public void testPullAggregateThroughUnion() {
> HepProgram program = new HepProgramBuilder()
> .addRuleInstance(AggregateProjectMergeRule.INSTANCE)
> .addRuleInstance(AggregateUnionAggregateRule.INSTANCE)
> .build();
> final String sql = "select job, deptno from"
> + " (select job, deptno from emp as e1"
> + " group by job, deptno"
> + " union all"
> + " select job, deptno from emp as e2"
> + " group by job, deptno)"
> + " group by job, deptno";
> sql(sql).with(program).check();
> }
> {code}
> {code:java}
> java.lang.IllegalArgumentException: Cannot compute compatible row type for
> arguments to set op: RecordType(VARCHAR(10) JOB, INTEGER DEPTNO),
> RecordType(INTEGER EMPNO, VARCHAR(20) ENAME, VARCHAR(10) JOB, INTEGER MGR,
> TIMESTAMP(0) HIREDATE, INTEGER SAL, INTEGER COMM, INTEGER DEPTNO, BOOLEAN
> SLACKER)
> at org.apache.calcite.rel.core.SetOp.deriveRowType(SetOp.java:111)
> at
> org.apache.calcite.rel.AbstractRelNode.getRowType(AbstractRelNode.java:222)
> at
> org.apache.calcite.tools.RelBuilder$Frame.(RelBuilder.java:2378)
> at
> org.apache.calcite.tools.RelBuilder$Frame.(RelBuilder.java:2363)
> at org.apache.calcite.tools.RelBuilder.push(RelBuilder.java:260)
> at org.apache.calcite.tools.RelBuilder.setOp(RelBuilder.java:1559)
> at org.apache.calcite.tools.RelBuilder.union(RelBuilder.java:1579)
> at org.apache.calcite.tools.RelBuilder.union(RelBuilder.java:1569)
> at
> org.apache.calcite.rel.rules.AggregateUnionAggregateRule.onMatch(AggregateUnionAggregateRule.java:130)
> at
> org.apache.calcite.plan.AbstractRelOptPlanner.fireRule(AbstractRelOptPlanner.java:319)
> at org.apache.calcite.plan.hep.HepPlanner.applyRule(HepPlanner.java:559)
> at
> org.apache.calcite.plan.hep.HepPlanner.applyRules(HepPlanner.java:418)
> at
> org.apache.calcite.plan.hep.HepPlanner.executeInstruction(HepPlanner.java:255)
> at
> org.apache.calcite.plan.hep.HepInstruction$RuleInstance.execute(HepInstruction.java:127)
> at
> org.apache.calcite.plan.hep.HepPlanner.executeProgram(HepPlanner.java:214)
> at
> org.apache.calcite.plan.hep.HepPlanner.findBestExp(HepPlanner.java:201)
> at
> org.apache.calcite.test.RelOptTestBase.checkPlanning(RelOptTestBase.java:206)
> at
> org.apache.calcite.test.RelOptTestBase$Sql.check(RelOptTestBase.java:334)
> at
> org.apache.calcite.test.RelOptTestBase$Sql.check(RelOptTestBase.java:317)
> at org.apache.calcite.test.RelOptRulesTest.testPullAggregateThroughUnion
> {code}
> I see two option to solve the problem:
> - Check the input type in {{AggregateUnionAggregateRule}} and exit the rule
> directly.
> - Add a Project with a same row type to the bottom Aggregate.
> What do you guys think? Thanks a lot.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2799) Allow alias in having clause for aggregate functions
[
https://issues.apache.org/jira/browse/CALCITE-2799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16752564#comment-16752564
]
Julian Hyde commented on CALCITE-2799:
--
I do, however, believe we should allow aliases for calls to aggregate
functions. For example, the following should be legal is {{isHavingAlias}} and
{{isGroupByAlias}} are true:
{code}select dept + 10 as dept10,
count(*) as c,
avg(salary + commission) as remuneration
from emp
group by dept10
having c > 3 and remuneration > 5{code}
> Allow alias in having clause for aggregate functions
>
>
> Key: CALCITE-2799
> URL: https://issues.apache.org/jira/browse/CALCITE-2799
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.18.0
>Reporter: Arina Ielchiieva
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.19.0
>
>
> Currently alias is not allowed in having for aggregate functions.
> MySql supports such cases and taking into account that alias in having clause
> is allowed only for the following conformance levels: MYSQL_5, LENIENT,
> BABEL, it makes sense to allow alias in having for aggregate functions.
> {noformat}
> /**
>* Whether to allow aliases from the {@code SELECT} clause to be used as
>* column names in the {@code HAVING} clause.
>*
>* Among the built-in conformance levels, true in
>* {@link SqlConformanceEnum#BABEL},
>* {@link SqlConformanceEnum#LENIENT},
>* {@link SqlConformanceEnum#MYSQL_5};
>* false otherwise.
>*/
> boolean isHavingAlias();
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2791) Add the JSON_TYPE function
[ https://issues.apache.org/jira/browse/CALCITE-2791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] xuqianjin updated CALCITE-2791: --- Description: The data in json can be =, <, <=, >, >=, <>,! =, and <=>. But the data types in json can be diverse, so when you compare different types, you have a priority, and the high priority is greater than the low priority (you can view the types with the JSON_TYPE() function). The priorities are as follows: BLOB BIT OPAQUE DATETIME TIME DATE BOOLEAN ARRAY OBJECT STRING INTEGER, DOUBLE NULL was: The data in json can be =, <, <=, >, >=, <>,! =, and <=>. But the data types in json can be diverse, so when you compare different types, you have a priority, and the high priority is greater than the low priority (you can view the types with the JSON_TYPE() function). The priorities are as follows: BLOB BIT OPAQUE DATETIME TIME DATE BOOLEAN ARRAY OBJECT STRING INTEGER, DOUBLE NULL > Add the JSON_TYPE function > -- > > Key: CALCITE-2791 > URL: https://issues.apache.org/jira/browse/CALCITE-2791 > Project: Calcite > Issue Type: Improvement >Reporter: xuqianjin >Assignee: Julian Hyde >Priority: Major > > The data in json can be =, <, <=, >, >=, <>,! =, and <=>. But the data types > in json can be diverse, so when you compare different types, you have a > priority, and the high priority is greater than the low priority (you can > view the types with the JSON_TYPE() function). The priorities are as follows: > BLOB > BIT > OPAQUE > DATETIME > TIME > DATE > BOOLEAN > ARRAY > OBJECT > STRING > INTEGER, > DOUBLE > NULL -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2791) Add the JSON_TYPE function
[ https://issues.apache.org/jira/browse/CALCITE-2791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] xuqianjin updated CALCITE-2791: --- Description: The data in json can be =, <, <=, >, >=, <>,! =, and <=>. But the data types in json can be diverse, so when you compare different types, you have a priority, and the high priority is greater than the low priority (you can view the types with the JSON_TYPE() function). The priorities are as follows: BOOLEAN ARRAY OBJECT STRING INTEGER LONG DOUBLE NULL was: The data in json can be =, <, <=, >, >=, <>,! =, and <=>. But the data types in json can be diverse, so when you compare different types, you have a priority, and the high priority is greater than the low priority (you can view the types with the JSON_TYPE() function). The priorities are as follows: BOOLEAN ARRAY OBJECT STRING INTEGER, DOUBLE NULL > Add the JSON_TYPE function > -- > > Key: CALCITE-2791 > URL: https://issues.apache.org/jira/browse/CALCITE-2791 > Project: Calcite > Issue Type: Improvement >Reporter: xuqianjin >Assignee: Julian Hyde >Priority: Major > > The data in json can be =, <, <=, >, >=, <>,! =, and <=>. But the data types > in json can be diverse, so when you compare different types, you have a > priority, and the high priority is greater than the low priority (you can > view the types with the JSON_TYPE() function). The priorities are as follows: > BOOLEAN > ARRAY > OBJECT > STRING > INTEGER > LONG > DOUBLE > NULL -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2791) Add the JSON_TYPE function
[ https://issues.apache.org/jira/browse/CALCITE-2791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] xuqianjin updated CALCITE-2791: --- Description: The data in json can be =, <, <=, >, >=, <>,! =, and <=>. But the data types in json can be diverse, so when you compare different types, you have a priority, and the high priority is greater than the low priority (you can view the types with the JSON_TYPE() function). The priorities are as follows: BOOLEAN ARRAY OBJECT STRING INTEGER, DOUBLE NULL was: The data in json can be =, <, <=, >, >=, <>,! =, and <=>. But the data types in json can be diverse, so when you compare different types, you have a priority, and the high priority is greater than the low priority (you can view the types with the JSON_TYPE() function). The priorities are as follows: BLOB BIT OPAQUE DATETIME TIME DATE BOOLEAN ARRAY OBJECT STRING INTEGER, DOUBLE NULL > Add the JSON_TYPE function > -- > > Key: CALCITE-2791 > URL: https://issues.apache.org/jira/browse/CALCITE-2791 > Project: Calcite > Issue Type: Improvement >Reporter: xuqianjin >Assignee: Julian Hyde >Priority: Major > > The data in json can be =, <, <=, >, >=, <>,! =, and <=>. But the data types > in json can be diverse, so when you compare different types, you have a > priority, and the high priority is greater than the low priority (you can > view the types with the JSON_TYPE() function). The priorities are as follows: > BOOLEAN > ARRAY > OBJECT > STRING > INTEGER, > DOUBLE > NULL -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2802) Druid adapter: Usage of range conditions like "2010-01-01 < timestamp" leads to incorrect results
[
https://issues.apache.org/jira/browse/CALCITE-2802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16752257#comment-16752257
]
Zoltan Haindrich commented on CALCITE-2802:
---
opened pr https://github.com/apache/calcite/pull/1012
> Druid adapter: Usage of range conditions like "2010-01-01 < timestamp" leads
> to incorrect results
> -
>
> Key: CALCITE-2802
> URL: https://issues.apache.org/jira/browse/CALCITE-2802
> Project: Calcite
> Issue Type: Bug
>Reporter: Zoltan Haindrich
>Assignee: Zoltan Haindrich
>Priority: Major
>
> Timestamp range conditions when the timestamp is on left hand side work
> correctly; however when the literal is on the left hand side results are
> missing.
> {code}
> @Test
> public void testRangeCalc() {
> final Fixture2 f = new Fixture2();
> checkDateRange(f,
> f.and(
> f.le(f.timestampLiteral(2011, Calendar.JANUARY, 1), f.t),
> f.le(f.t, f.timestampLiteral(2012, Calendar.FEBRUARY, 2))),
> is("[2011-01-01T00:00:00.000Z/2012-02-02T00:00:00.001Z]"));
> }
> {code}
> Fail:
> {code}
> java.lang.AssertionError:
> Expected: is "[2011-01-01T00:00:00.000Z/2012-02-02T00:00:00.001Z]"
> but: was "[1900-01-01T00:00:00.000Z/2011-01-01T00:00:00.001Z]"
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2801) Check input type in AggregateUnionAggregateRule when remove the bottom Aggregate
[
https://issues.apache.org/jira/browse/CALCITE-2801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16752189#comment-16752189
]
Hequn Cheng commented on CALCITE-2801:
--
Hi [~julianhyde] , thanks a lot for the valuable suggestions. I will watch out
for this. We can make sure that the Project only be added if needed in
{{AggregateUnionAggregateRule}}, i.e., union input types are not same when the
bottom aggregate is pulled up. I will also try to check if there are other
rules that will remove the "fixup" Project as it will also cause cycles.
I will give it a try. Thank you very much!
> Check input type in AggregateUnionAggregateRule when remove the bottom
> Aggregate
>
>
> Key: CALCITE-2801
> URL: https://issues.apache.org/jira/browse/CALCITE-2801
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Hequn Cheng
>Assignee: Hequn Cheng
>Priority: Major
>
> In {{AggregateUnionAggregateRule}}, we may remove the bottom Aggregate and
> use it's input as the new input of Union directly. However, the bottom
> Aggregate and it's input may not share the same row type. As Union requires
> all inputs with a same row type, once we remove the bottom Aggregate, an
> exception will be thrown.
> The exception can be reproduced by the following test:
> {code:java}
> @Test public void testPullAggregateThroughUnion() {
> HepProgram program = new HepProgramBuilder()
> .addRuleInstance(AggregateProjectMergeRule.INSTANCE)
> .addRuleInstance(AggregateUnionAggregateRule.INSTANCE)
> .build();
> final String sql = "select job, deptno from"
> + " (select job, deptno from emp as e1"
> + " group by job, deptno"
> + " union all"
> + " select job, deptno from emp as e2"
> + " group by job, deptno)"
> + " group by job, deptno";
> sql(sql).with(program).check();
> }
> {code}
> {code:java}
> java.lang.IllegalArgumentException: Cannot compute compatible row type for
> arguments to set op: RecordType(VARCHAR(10) JOB, INTEGER DEPTNO),
> RecordType(INTEGER EMPNO, VARCHAR(20) ENAME, VARCHAR(10) JOB, INTEGER MGR,
> TIMESTAMP(0) HIREDATE, INTEGER SAL, INTEGER COMM, INTEGER DEPTNO, BOOLEAN
> SLACKER)
> at org.apache.calcite.rel.core.SetOp.deriveRowType(SetOp.java:111)
> at
> org.apache.calcite.rel.AbstractRelNode.getRowType(AbstractRelNode.java:222)
> at
> org.apache.calcite.tools.RelBuilder$Frame.(RelBuilder.java:2378)
> at
> org.apache.calcite.tools.RelBuilder$Frame.(RelBuilder.java:2363)
> at org.apache.calcite.tools.RelBuilder.push(RelBuilder.java:260)
> at org.apache.calcite.tools.RelBuilder.setOp(RelBuilder.java:1559)
> at org.apache.calcite.tools.RelBuilder.union(RelBuilder.java:1579)
> at org.apache.calcite.tools.RelBuilder.union(RelBuilder.java:1569)
> at
> org.apache.calcite.rel.rules.AggregateUnionAggregateRule.onMatch(AggregateUnionAggregateRule.java:130)
> at
> org.apache.calcite.plan.AbstractRelOptPlanner.fireRule(AbstractRelOptPlanner.java:319)
> at org.apache.calcite.plan.hep.HepPlanner.applyRule(HepPlanner.java:559)
> at
> org.apache.calcite.plan.hep.HepPlanner.applyRules(HepPlanner.java:418)
> at
> org.apache.calcite.plan.hep.HepPlanner.executeInstruction(HepPlanner.java:255)
> at
> org.apache.calcite.plan.hep.HepInstruction$RuleInstance.execute(HepInstruction.java:127)
> at
> org.apache.calcite.plan.hep.HepPlanner.executeProgram(HepPlanner.java:214)
> at
> org.apache.calcite.plan.hep.HepPlanner.findBestExp(HepPlanner.java:201)
> at
> org.apache.calcite.test.RelOptTestBase.checkPlanning(RelOptTestBase.java:206)
> at
> org.apache.calcite.test.RelOptTestBase$Sql.check(RelOptTestBase.java:334)
> at
> org.apache.calcite.test.RelOptTestBase$Sql.check(RelOptTestBase.java:317)
> at org.apache.calcite.test.RelOptRulesTest.testPullAggregateThroughUnion
> {code}
> I see two option to solve the problem:
> - Check the input type in {{AggregateUnionAggregateRule}} and exit the rule
> directly.
> - Add a Project with a same row type to the bottom Aggregate.
> What do you guys think? Thanks a lot.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
