[jira] [Comment Edited] (SOLR-16243) Compile SQL to a Streaming Expressions while visiting the Calcite SQL parse tree

["Joel Bernstein (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SOLR-16243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17551609#comment-17551609 ] 

Joel Bernstein edited comment on SOLR-16243 at 6/8/22 12:59 PM:
----------------------------------------------------------------

There are three types of nodes in the parse tree that will effect the compilation. Each type of node requires different visitor behavior.

1) Binary branches (Joins, Intersections etc...)
2) Unary branches (SolrProject, SolrFilter, SolrAggregate, SolrSort)
3) Leaf nodes (Always SolrTableScan)

In the initial implementation we only need to deal with unary and leaf nodes. When we get to the join implementations we'll need to deal with binary branches

The behavior of the visitor/implementor is as follows in this ticket:

1) Each unary node, which is any node that is not SolrTableScan, gather the information from the node and pass it down to the single child.
2) The SolrTableScan leaf node will then create a Streaming Expression object tree and reverse compile it to a StreamingExpression String. This moves the core logic compilation from the SolrTable to the SolrTableScan.

The implementer will then pass the Streaming Expression string to the SolrTable for the execution of the query and return of the Enumeratable.

This puts us in good position to add the join logic in future tickets.




 







was (Author: joel.bernstein):

There are three types of nodes in the parse tree to will effect the compilation. Each type of node requires different compilation visitor behavior.

1) Binary branches (Joins, Intersections etc...)
2) Unary branches (SolrProject, SolrFilter, SolrAggregate, SolrSort)
3) Leaf nodes (Always SolrTableScan)

In the initial implementation we only need to deal with unary and leaf nodes. When we get to the join implementations we'll need to deal with binary branches

The behavior of the visitor/implementor is as follows in this ticket:

1) Each unary node, which is any node that is not SolrTableScan, gather the information from the node and pass it down to the single child.
2) The SolrTableScan leaf node will then create a Streaming Expression object tree and reverse compile it to a StreamingExpression String. This moves the core logic compilation from the SolrTable to the SolrTableScan.

The implementer will then pass the Streaming Expression string to the SolrTable for the execution of the query and return of the Enumeratable.

This puts us in good position to add the join logic in future tickets.




 






> Compile SQL to a Streaming Expressions while visiting the Calcite SQL parse tree
> --------------------------------------------------------------------------------
>
>                 Key: SOLR-16243
>                 URL: https://issues.apache.org/jira/browse/SOLR-16243
>             Project: Solr
>          Issue Type: Improvement
>      Security Level: Public(Default Security Level. Issues are Public) 
>          Components: Parallel SQL
>            Reporter: Joel Bernstein
>            Priority: Major
>              Labels: RobustSQL
>
> Currently Solr SQL visits the SQL parse tree and builds up a set of properties that are passed to the SolrTable which creates the Streaming Expression object tree. This technique only works because we're not dealing yet with Joins. It won't be practical to express joins using the current approach. In order to support joins we'll need to build the Streaming Expression as we visit the parse tree and pass the expression directly to the SolrTable. 
> This ticket will only implement existing SQL support using the direct compilation approach.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org