[
https://issues.apache.org/jira/browse/CALCITE-968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15020832#comment-15020832
]
Milinda Lakmal Pathirage edited comment on CALCITE-968 at 11/22/15 4:37 AM:
----------------------------------------------------------------------------
Hi [~julianhyde],
I simply modified the {{DeltaTableScanRule}} rule to transform call to empty
LogicalValues node if the table scan is not for a streamable table. when tried
with this modification, PruneEmptyRules' UNION_INSTANCE failed with a
NullPointerException due to {{call.getChildRels(union)}} returning null. Then I
replace that call with {{union.getInputs()}}. But now the rule fails saying
'planner promised us at least one Empty child'. I did some debugging and found
out that this rule is matched even when union inputs are instance of
{{RelSubset}} with one of the rels in the subset is an empty LogicalValues
instance. But {{isEmpty}} method invoked on the inputs doesn't handle this
situation. It just checks whether the input node is an instance of Values and
if not returns {{false}}. It looks like this is a bug. But I am not 100% sure.
Changes related to this issue can be found in
https://github.com/milinda/calcite/tree/CALCITE-968-pruneempty-bug branch.
was (Author: milinda):
Hi [~julianhyde],
I simply modified the {{DeltaTableScanRule}} rule to transform call to empty
LogicalValues node if the table scan is not for a streamable table. when tried
with this modificaiton, PruneEmptyRules' UNION_INSTANCE failed with a
NullPointerException due to {{call.getChildRels(union)}} returning null. Then I
replace that call with {{union.getInputs()}}. But now the rule fails saying
'planner promised us at least one Empty child'. I did some debugging and found
out that this rule is matched even when union inputs are instance of
{{RelSubset}} with one of the rels in the subset is an empty LogicalValues
instance. But {{isEmpty}} method invoked on the inputs doesn't handle this
situation. It just checks whether the input node is an instance of Values and
if not returns {{false}}. It looks like this is a bug. But I am not 100% sure.
Changes related to this issue can be found in
https://github.com/milinda/calcite/tree/CALCITE-968-pruneempty-bug branch.
> Support stream joins
> --------------------
>
> Key: CALCITE-968
> URL: https://issues.apache.org/jira/browse/CALCITE-968
> Project: Calcite
> Issue Type: New Feature
> Components: core, stream
> Reporter: Milinda Lakmal Pathirage
> Assignee: Julian Hyde
> Attachments: CALCITE-968-0.patch
>
>
> Stream joins are used to relate information from different streams or stream
> and relation combinations. Calcite lacks (proper) support for
> stream-to-relation joins and stream-to-stream joins.
> stream-to-relation join like below fails at the SQL validation stage.
> select stream orders.orderId, orders.productId, products.name from orders
> join products on orders.productId = products.id
> But if 'products' is a stream, the query is valid according to Calcite, even
> though the stream-to-stream join in above query is not valid due to unbounded
> nature of streams.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
