[jira] [Commented] (CALCITE-3176) File adapter for parsing JSON files
[
https://issues.apache.org/jira/browse/CALCITE-3176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16889301#comment-16889301
]
Michael Mior commented on CALCITE-3176:
---
Fixed in
[{{ab71c4c}}|https://github.com/apache/calcite/commit/ab71c4cae5a5c3c7d979337a2d38ddaf271aa206].
> File adapter for parsing JSON files
> ---
>
> Key: CALCITE-3176
> URL: https://issues.apache.org/jira/browse/CALCITE-3176
> Project: Calcite
> Issue Type: New Feature
>Reporter: Forward Xu
>Assignee: Michael Mior
>Priority: Major
> Labels: pull-request-available
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> File adapter for parsing JSON files
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Resolved] (CALCITE-3176) File adapter for parsing JSON files
[ https://issues.apache.org/jira/browse/CALCITE-3176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Mior resolved CALCITE-3176. --- Resolution: Fixed > File adapter for parsing JSON files > --- > > Key: CALCITE-3176 > URL: https://issues.apache.org/jira/browse/CALCITE-3176 > Project: Calcite > Issue Type: New Feature >Reporter: Forward Xu >Assignee: Michael Mior >Priority: Major > Labels: pull-request-available > Time Spent: 1h 20m > Remaining Estimate: 0h > > File adapter for parsing JSON files -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (CALCITE-3197) Convert data of Timestamp/Time/Date as original form when enumerating from ArrayTable
[
https://issues.apache.org/jira/browse/CALCITE-3197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16889299#comment-16889299
]
Julian Hyde commented on CALCITE-3197:
--
Actually, cancel that.
When in enumerable convention, the correct format for SQL TIMESTAMP values is
as a long or Long. If you want them as java.sql.Timestamp, convert to JDBC
convention (i.e. using JdbcToEnumerableConverter).
It is not possible to convert a long (SQL TIMESTAMP) to a java.sql.Timestamp.
There is simply not enough information. You have to know what timezone the
TIMESTAMP is in, which means you have to call an API (such as
{{ResultSet.getTimestamp(int, Calendar)}}) that provides a timezone.
> Convert data of Timestamp/Time/Date as original form when enumerating from
> ArrayTable
> -
>
> Key: CALCITE-3197
> URL: https://issues.apache.org/jira/browse/CALCITE-3197
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: jin xing
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In current implementation ColumnLoader, data of
> {{Rep.JAVA_SQL_TIMESTAMP/Rep.JAVA_SQL_TIME/Rep.JAVA_SQL_DATE}} are converted
> as numeric during loading.
> https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/adapter/clone/ColumnLoader.java#L234
> But current code seems forgot to revert the data back to original form when
> enumerating.
> As a result, below test is failing now
> {code:java}
> // MaterializationTest.java
> @Test public void testTimestampType() {
> String sql = "select \"eventid\", \"ts\"\n"
> + "from \"events\"\n"
> + "where \"eventid\" > 5";
> checkMaterialize(sql, sql);
> }{code}
> For type of {{Rep.JAVA_SQL_TIMESTAMP/Rep.JAVA_SQL_TIME/Rep.JAVA_SQL_DATE}},
> cursor acesses by {{TimestampAccessor/TimeAccessor/DateAccessor}}, which
> expect column value as {{Timestamp/Time/Date}}.
> It make sense to 'unwrap' the data as original form when enumerating from
> {{ArrayTable}}.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (CALCITE-3197) Convert data of Timestamp/Time/Date as original form when enumerating from ArrayTable
[
https://issues.apache.org/jira/browse/CALCITE-3197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16889298#comment-16889298
]
Julian Hyde commented on CALCITE-3197:
--
Column should not have an unwrapper field. It already has a Representation,
which is an interface. Can you not just create an implementation of
Representation that unwraps appropriately. I don't think you need to add any
new methods to Representation.
> Convert data of Timestamp/Time/Date as original form when enumerating from
> ArrayTable
> -
>
> Key: CALCITE-3197
> URL: https://issues.apache.org/jira/browse/CALCITE-3197
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: jin xing
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In current implementation ColumnLoader, data of
> {{Rep.JAVA_SQL_TIMESTAMP/Rep.JAVA_SQL_TIME/Rep.JAVA_SQL_DATE}} are converted
> as numeric during loading.
> https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/adapter/clone/ColumnLoader.java#L234
> But current code seems forgot to revert the data back to original form when
> enumerating.
> As a result, below test is failing now
> {code:java}
> // MaterializationTest.java
> @Test public void testTimestampType() {
> String sql = "select \"eventid\", \"ts\"\n"
> + "from \"events\"\n"
> + "where \"eventid\" > 5";
> checkMaterialize(sql, sql);
> }{code}
> For type of {{Rep.JAVA_SQL_TIMESTAMP/Rep.JAVA_SQL_TIME/Rep.JAVA_SQL_DATE}},
> cursor acesses by {{TimestampAccessor/TimeAccessor/DateAccessor}}, which
> expect column value as {{Timestamp/Time/Date}}.
> It make sense to 'unwrap' the data as original form when enumerating from
> {{ArrayTable}}.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (CALCITE-2589) VolcanoPlanner#fireRules and VolcanoRuleCall#matchRecurse should ignore known-to-be-unimportant relations
[
https://issues.apache.org/jira/browse/CALCITE-2589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16889296#comment-16889296
]
Julian Hyde commented on CALCITE-2589:
--
That would be OK.
If we start to see people adding {{setImportance(0)}} calls to existing rules
we should revisit urgently. I don't want people to start relying on this crutch.
> VolcanoPlanner#fireRules and VolcanoRuleCall#matchRecurse should ignore
> known-to-be-unimportant relations
> -
>
> Key: CALCITE-2589
> URL: https://issues.apache.org/jira/browse/CALCITE-2589
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.17.0
>Reporter: Vladimir Sitnikov
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.21.0
>
>
> {{call.getPlanner().setImportance}} is used to avoid use of
> known-to-be-inefficient relation, however the check of importance is
> performed very late.
> The check is performed in org.apache.calcite.plan.volcano.RuleQueue#skipMatch
> when ruleCalls have already been created.
> I suggest to move the check into VolcanoPlanner#fireRules and
> VolcanoRuleCall#matchRecurse
> It would reduce amount of "possible" rule executions.
> Note: calling setImportance BEFORE transformTo would would help as well to
> filter out unimportant rule calls early.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (CALCITE-2589) VolcanoPlanner#fireRules and VolcanoRuleCall#matchRecurse should ignore known-to-be-unimportant relations
[
https://issues.apache.org/jira/browse/CALCITE-2589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1656#comment-1656
]
Stamatis Zampetakis commented on CALCITE-2589:
--
>From the discussion so far I understand that the changed proposed by
>[~vladimirsitnikov] is purely an internal optimization. I agree with
>[~julianhyde] that possibly setting importance to 0 is not a very good idea
>but our built-in rules use it and there is no ongoing discussion about
>deprecating/removing this method. I would suggest to proceed with this change
>that only affects performance and debate on another Jira about removing or not
> {{RelOptPlanner.setImportance}}. What do you think?
> VolcanoPlanner#fireRules and VolcanoRuleCall#matchRecurse should ignore
> known-to-be-unimportant relations
> -
>
> Key: CALCITE-2589
> URL: https://issues.apache.org/jira/browse/CALCITE-2589
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.17.0
>Reporter: Vladimir Sitnikov
>Priority: Major
> Labels: pull-request-available
>
> {{call.getPlanner().setImportance}} is used to avoid use of
> known-to-be-inefficient relation, however the check of importance is
> performed very late.
> The check is performed in org.apache.calcite.plan.volcano.RuleQueue#skipMatch
> when ruleCalls have already been created.
> I suggest to move the check into VolcanoPlanner#fireRules and
> VolcanoRuleCall#matchRecurse
> It would reduce amount of "possible" rule executions.
> Note: calling setImportance BEFORE transformTo would would help as well to
> filter out unimportant rule calls early.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (CALCITE-2589) VolcanoPlanner#fireRules and VolcanoRuleCall#matchRecurse should ignore known-to-be-unimportant relations
[
https://issues.apache.org/jira/browse/CALCITE-2589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stamatis Zampetakis updated CALCITE-2589:
-
Fix Version/s: 1.21.0
> VolcanoPlanner#fireRules and VolcanoRuleCall#matchRecurse should ignore
> known-to-be-unimportant relations
> -
>
> Key: CALCITE-2589
> URL: https://issues.apache.org/jira/browse/CALCITE-2589
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.17.0
>Reporter: Vladimir Sitnikov
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.21.0
>
>
> {{call.getPlanner().setImportance}} is used to avoid use of
> known-to-be-inefficient relation, however the check of importance is
> performed very late.
> The check is performed in org.apache.calcite.plan.volcano.RuleQueue#skipMatch
> when ruleCalls have already been created.
> I suggest to move the check into VolcanoPlanner#fireRules and
> VolcanoRuleCall#matchRecurse
> It would reduce amount of "possible" rule executions.
> Note: calling setImportance BEFORE transformTo would would help as well to
> filter out unimportant rule calls early.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Assigned] (CALCITE-3176) File adapter for parsing JSON files
[ https://issues.apache.org/jira/browse/CALCITE-3176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Mior reassigned CALCITE-3176: - Assignee: Michael Mior (was: Forward Xu) > File adapter for parsing JSON files > --- > > Key: CALCITE-3176 > URL: https://issues.apache.org/jira/browse/CALCITE-3176 > Project: Calcite > Issue Type: New Feature >Reporter: Forward Xu >Assignee: Michael Mior >Priority: Major > Labels: pull-request-available > Time Spent: 0.5h > Remaining Estimate: 0h > > File adapter for parsing JSON files -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (CALCITE-3202) AssertionError in ElasticsearchAggregate constructor when applying AggregateProjectMergeRule
[
https://issues.apache.org/jira/browse/CALCITE-3202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stamatis Zampetakis updated CALCITE-3202:
-
Summary: AssertionError in ElasticsearchAggregate constructor when applying
AggregateProjectMergeRule (was: ElasticsearchAggregate constructor throws an
AssertionError while applying AggregateProjectMergeRule by VolcanoPlanner)
> AssertionError in ElasticsearchAggregate constructor when applying
> AggregateProjectMergeRule
>
>
> Key: CALCITE-3202
> URL: https://issues.apache.org/jira/browse/CALCITE-3202
> Project: Calcite
> Issue Type: Bug
> Components: elasticsearch-adapter
>Affects Versions: 1.21.0
>Reporter: guoyangqiao
>Priority: Critical
> Attachments: log.log.zip, mapping.json
>
>
> Thanks for viewing this issue! The error occurs when I was trying to execute
> a query with some subquery:
> {code:java}
> select distinct uni_id
> from (
> select uni_id from sample_index where customer_child = 'customer' and
> customer_from_plat = 'FOO'
> and uni_id in (select uni_id from sample_index where customer_child =
> 'trade' and shop_id = '60790435')
> and uni_id in (select uni_id from sample_index where customer_child =
> 'member' and member_id = '884225534')
> )
> {code}
> While running code below:
> {code:java}
> ElasticsearchAggregate(RelOptCluster cluster,
> RelTraitSet traitSet,
> RelNode input,
> ImmutableBitSet groupSet,
> List groupSets,
> List aggCalls) throws InvalidRelException {
> super(cluster, traitSet, input, groupSet, groupSets, aggCalls);
> if (getConvention() != input.getConvention()) {
> String message = String.format(Locale.ROOT, "%s != %s", getConvention(),
> input.getConvention());
> throw new AssertionError(message);
> }{code}
> an AssertionError which means an input of ElasticsearchAggregate has a
> Convention of NONE throws out. stack traces shows as below:
> {code:java}
> java.lang.AssertionError: ELASTICSEARCH != NONE
> at
> org.apache.calcite.adapter.elasticsearch.ElasticsearchAggregate.(ElasticsearchAggregate.java:66)
> at
> org.apache.calcite.adapter.elasticsearch.ElasticsearchAggregate.copy(ElasticsearchAggregate.java:112)
> at
> org.apache.calcite.rel.rules.AggregateProjectMergeRule.apply(AggregateProjectMergeRule.java:113)
> at
> org.apache.calcite.rel.rules.AggregateProjectMergeRule.onMatch(AggregateProjectMergeRule.java:72)
> at
> org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:208)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.findBestExp(VolcanoPlanner.java:631)
> at org.apache.calcite.tools.Programs.lambda$standard$3(Programs.java:283)
> at org.apache.calcite.tools.Programs$SequenceProgram.run(Programs.java:343)
> at org.apache.calcite.prepare.Prepare.optimize(Prepare.java:189)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:320)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:231)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:637)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:501)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:471)
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:231)
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl.prepareStatement_(CalciteConnectionImpl.java:213)
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl.prepareStatement(CalciteConnectionImpl.java:202)
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl.prepareStatement(CalciteConnectionImpl.java:93)
> at
> org.apache.calcite.avatica.AvaticaConnection.prepareStatement(AvaticaConnection.java:175)
> at SearchTest.main(SearchTest.java:25)
> {code}
> And before the volcano planner start to work, the algebra expression looks
> like this:
> {code:java}
> LogicalAggregate(group=[{0}])
> LogicalProject(uni_id=[$2])
> LogicalFilter(condition=[AND(=($0, 'customer'), =($1, 'FOO'))])
> LogicalJoin(condition=[=($2, $4)], joinType=[inner])
> LogicalJoin(condition=[=($2, $3)], joinType=[inner])
> LogicalProject(customer_child=[CAST(ITEM($0,
> 'customer_child')):VARCHAR(65535)], customer_from_plat=[CAST(ITEM($0,
> 'customer_from_plat')):VARCHAR(255)], uni_id=[CAST(ITEM($0,
> 'uni_id')):VARCHAR(255)])
> ElasticsearchTableScan(table=[[elasticsearch_raw, sample_index]])
> LogicalAggregate(group=[{0}])
> LogicalProject(uni_id=[$2])
> LogicalFilter(condition=[AND(=($0, 'trade'), =($1,
> '60790435'))])
> LogicalProject(customer_child=[CAST(ITEM($0,
> 'customer_child')):VARCHAR(65535)], shop_id=[CAST(ITEM($0,
[jira] [Commented] (CALCITE-3167) Remove overriding equals and hashCode methods in EnumerableTableScan
[
https://issues.apache.org/jira/browse/CALCITE-3167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1611#comment-1611
]
jin xing commented on CALCITE-3167:
---
[~amargoor]
Gentle ping ~ ideas on this ?
> Remove overriding equals and hashCode methods in EnumerableTableScan
>
>
> Key: CALCITE-3167
> URL: https://issues.apache.org/jira/browse/CALCITE-3167
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.19.0
>Reporter: jin xing
>Priority: Minor
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> In current code of {{EnumerableTableScan}}, methods of equals and hashCode
> are overridden for matching of {{EnumerableTableScan}}s.
> While after optimizing with the same HEP planner, {{EnumerableTableScan}}s
> from two plans but with the same digest will the share the same Java object.
> See
> [RelOptMaterializations|https://github.com/apache/calcite/blob/adf4cc4dc5cdb9f5e49c85d10f46a2fdcd831ccf/core/src/main/java/org/apache/calcite/plan/RelOptMaterializations.java#L192].
> I think it's ok to remove the redundant overriding methods in
> {{EnumerableTableScan}}.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (CALCITE-3197) Convert data of Timestamp/Time/Date as original form when enumerating from ArrayTable
[
https://issues.apache.org/jira/browse/CALCITE-3197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1610#comment-1610
]
jin xing commented on CALCITE-3197:
---
[~julianhyde]
As you shepherded -- it's bad idea to let representation know what it "really
should be", In current change I set the {{unwrapper}} into
{{ArrayTable.Column}} and unwrap when enumerate records. But checking the
patch, I think it's still bigger than your expectation.
Please check the patch again when you have time. If the fix is far from your
idea, it's great if you can point better direction
> Convert data of Timestamp/Time/Date as original form when enumerating from
> ArrayTable
> -
>
> Key: CALCITE-3197
> URL: https://issues.apache.org/jira/browse/CALCITE-3197
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: jin xing
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In current implementation ColumnLoader, data of
> {{Rep.JAVA_SQL_TIMESTAMP/Rep.JAVA_SQL_TIME/Rep.JAVA_SQL_DATE}} are converted
> as numeric during loading.
> https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/adapter/clone/ColumnLoader.java#L234
> But current code seems forgot to revert the data back to original form when
> enumerating.
> As a result, below test is failing now
> {code:java}
> // MaterializationTest.java
> @Test public void testTimestampType() {
> String sql = "select \"eventid\", \"ts\"\n"
> + "from \"events\"\n"
> + "where \"eventid\" > 5";
> checkMaterialize(sql, sql);
> }{code}
> For type of {{Rep.JAVA_SQL_TIMESTAMP/Rep.JAVA_SQL_TIME/Rep.JAVA_SQL_DATE}},
> cursor acesses by {{TimestampAccessor/TimeAccessor/DateAccessor}}, which
> expect column value as {{Timestamp/Time/Date}}.
> It make sense to 'unwrap' the data as original form when enumerating from
> {{ArrayTable}}.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Resolved] (CALCITE-3182) Trim unused fields for plan of materialized-view before matching.
[
https://issues.apache.org/jira/browse/CALCITE-3182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ruben Quesada Lopez resolved CALCITE-3182.
--
Resolution: Fixed
Fixed in
https://github.com/apache/calcite/commit/58b6ad6135d909c053f15fb902d8b73559d1fa53
Thanks for the PR [~jinxing6...@126.com]!
> Trim unused fields for plan of materialized-view before matching.
> -
>
> Key: CALCITE-3182
> URL: https://issues.apache.org/jira/browse/CALCITE-3182
> Project: Calcite
> Issue Type: Bug
>Reporter: jin xing
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.21.0
>
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> In current code, before matching query with materialized-view, unused fields
> of query is trimmed but materialized-view is not. Thus below simple SQL fails
> to be matched though query and materialized-
> view are exactly the same:
> {code:java}
> @Test public void testMaterializationAfterTrimingOfUnusedFields() {
> String sql =
> "select \"y\".\"deptno\", \"y\".\"name\", \"x\".\"sum_salary\"\n" +
> "from\n" +
> " (select \"deptno\", sum(\"salary\") \"sum_salary\" from \"emps\" group by
> \"deptno\") \"x\"\n" +
> " join\n" +
> " \"depts\" \"y\"\n" +
> " on \"x\".\"deptno\"=\"y\".\"deptno\"\n";
> checkMaterialize(sql, sql);
> }{code}
> Checking {{CalciteMaterializer}}
> [https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/prepare/CalciteMaterializer.java#L83]
> , I think the code intends to do the trimming, but didn't call the method.
> Since unused fields of query is trimmed anyway
> [https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/prepare/CalcitePrepareImpl.java#L995]
> , thus I think there's no necessity to keep the materialized-view un-trimmed
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (CALCITE-3182) Trim unused fields for plan of materialized-view before matching.
[
https://issues.apache.org/jira/browse/CALCITE-3182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ruben Quesada Lopez updated CALCITE-3182:
-
Fix Version/s: 1.21.0
> Trim unused fields for plan of materialized-view before matching.
> -
>
> Key: CALCITE-3182
> URL: https://issues.apache.org/jira/browse/CALCITE-3182
> Project: Calcite
> Issue Type: Bug
>Reporter: jin xing
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.21.0
>
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> In current code, before matching query with materialized-view, unused fields
> of query is trimmed but materialized-view is not. Thus below simple SQL fails
> to be matched though query and materialized-
> view are exactly the same:
> {code:java}
> @Test public void testMaterializationAfterTrimingOfUnusedFields() {
> String sql =
> "select \"y\".\"deptno\", \"y\".\"name\", \"x\".\"sum_salary\"\n" +
> "from\n" +
> " (select \"deptno\", sum(\"salary\") \"sum_salary\" from \"emps\" group by
> \"deptno\") \"x\"\n" +
> " join\n" +
> " \"depts\" \"y\"\n" +
> " on \"x\".\"deptno\"=\"y\".\"deptno\"\n";
> checkMaterialize(sql, sql);
> }{code}
> Checking {{CalciteMaterializer}}
> [https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/prepare/CalciteMaterializer.java#L83]
> , I think the code intends to do the trimming, but didn't call the method.
> Since unused fields of query is trimmed anyway
> [https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/prepare/CalcitePrepareImpl.java#L995]
> , thus I think there's no necessity to keep the materialized-view un-trimmed
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (CALCITE-3200) Add TEXT Data Type
[ https://issues.apache.org/jira/browse/CALCITE-3200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16888560#comment-16888560 ] pingle wang commented on CALCITE-3200: -- If the request cannot use TEXT in the parser, then my PR is not suitable. alright, I got it. > Add TEXT Data Type > -- > > Key: CALCITE-3200 > URL: https://issues.apache.org/jira/browse/CALCITE-3200 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.20.0 >Reporter: pingle wang >Priority: Major > Labels: pull-request-available > Fix For: next > > Time Spent: 20m > Remaining Estimate: 0h > > 1. SQL Server, Mysql, Oracle support TEXT data type. > 2. java.sql.Types LONGVARCHAR is TEXT. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (CALCITE-3128) Joining two tables producing only NULLs will return 0 rows
[
https://issues.apache.org/jira/browse/CALCITE-3128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16888558#comment-16888558
]
Danny Chan commented on CALCITE-3128:
-
[~julianhyde] Because you seem to have objections for this PR, can you take a
look for this issue again ?
> Joining two tables producing only NULLs will return 0 rows
> --
>
> Key: CALCITE-3128
> URL: https://issues.apache.org/jira/browse/CALCITE-3128
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.20.0
>Reporter: Muhammad Gelbana
>Assignee: Danny Chan
>Priority: Major
> Labels: pull-request-available
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> The following queries will return 0 rows while they're expected to ruturn
> rows with NULLs in them.
> {code:sql}
> SELECT *
> FROM (SELECT NULLIF(5, 5)) a, (SELECT NULLIF(5, 5)) b
> {code}
> {code:sql}
> SELECT *
> FROM (VALUES (NULLIF(5, 5)), (NULLIF(5, 5))) a, (VALUES (NULLIF(5, 5)),
> (NULLIF(5, 5))) b
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Resolved] (CALCITE-3174) IS NOT DISTINCT FROM condition pushed from filter to join is not collapsed
[
https://issues.apache.org/jira/browse/CALCITE-3174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Danny Chan resolved CALCITE-3174.
-
Resolution: Fixed
Fix Version/s: 1.21.0
Fixed in
[6d7eca1|https://github.com/apache/calcite/commit/6d7eca19bb0a22d059abe4e283d003d2848e55af],
thanks for your PR, [~KazydubB]!
> IS NOT DISTINCT FROM condition pushed from filter to join is not collapsed
> --
>
> Key: CALCITE-3174
> URL: https://issues.apache.org/jira/browse/CALCITE-3174
> Project: Calcite
> Issue Type: Bug
>Reporter: Bohdan Kazydub
>Assignee: Danny Chan
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.21.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> If filter containing {{IS NOT DISTINCT FROM}} expression is pushed to join,
> this results to new join condition having this expanded {{IS NOT DISTINCT
> FROM}} expression (and not collapsed one), which can be further modified
> making impossible to identify the {{IS NOT DISTINCT FROM}} condition.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Assigned] (CALCITE-3174) IS NOT DISTINCT FROM condition pushed from filter to join is not collapsed
[
https://issues.apache.org/jira/browse/CALCITE-3174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Danny Chan reassigned CALCITE-3174:
---
Assignee: Danny Chan (was: Bohdan Kazydub)
> IS NOT DISTINCT FROM condition pushed from filter to join is not collapsed
> --
>
> Key: CALCITE-3174
> URL: https://issues.apache.org/jira/browse/CALCITE-3174
> Project: Calcite
> Issue Type: Bug
>Reporter: Bohdan Kazydub
>Assignee: Danny Chan
>Priority: Major
> Labels: pull-request-available
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> If filter containing {{IS NOT DISTINCT FROM}} expression is pushed to join,
> this results to new join condition having this expanded {{IS NOT DISTINCT
> FROM}} expression (and not collapsed one), which can be further modified
> making impossible to identify the {{IS NOT DISTINCT FROM}} condition.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
