[
https://issues.apache.org/jira/browse/SOLR-16243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17552346#comment-17552346
]
Joel Bernstein edited comment on SOLR-16243 at 6/9/22 5:40 PM:
---------------------------------------------------------------
[~krisden] the PR is now working so you can how it shaped up. You'll see most
of the work is simply moving the logic for building the Streaming Expression
from the SolrTable to the SolrTableScan. The Streaming Expression string is
then passed to the SolrTable to execute so the SolrTable has very little code
in it now.
Here is the description from the PR with more details:
_emphasized text_
This PR is a refactoring of Solr SQL (no new features) to compile the streaming
expression directly from the Calcite logical plan tree. This replaces the old
approach which traversed the logical plan tree and gathered information into a
flattened structure which was passed to the SolrTable which built the streaming
expression. The old approach worked fine to represent a SQL query which mapped
to a single Solr query, but would not work well for representing SQL joins
which map to two Solr queries (left and right side of the join).
The new approach directly translates from one DAG (Calcite logical plan) to
another DAG (streaming expression) so it can support more complex queries like
joins in the future.
was (Author: joel.bernstein):
[~krisden] the PR is now working so you can how it shaped up. You'll see most
of the work is simply moving the logic for building the Streaming Expression
from the SolrTable to the SolrTableScan. The Streaming Expression string is
then passed to the SolrTable to execute so the SolrTable has very little code
in it now.
Here is the description from the PR with more details:
_This PR is a refactoring of Solr SQL (no new features) to compile the
streaming expression directly from the Calcite logical plan tree. This replaces
the old approach which traversed the logical plan tree and gathered information
into a flattened structure which was passed to the SolrTable which built the
streaming expression. The old approach worked fine to represent a SQL query
which mapped to a single Solr query, but would not work well for representing
SQL joins which map to two Solr queries (left and right side of the join).
The new approach directly translates from one DAG (Calcite logical plan) to
another DAG (streaming expression) so it can support more complex queries like
joins in the future.
_
> Compile SQL to a Streaming Expression 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
> Assignee: Joel Bernstein
> Priority: Major
> Labels: RobustSQL
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 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: [email protected]
For additional commands, e-mail: [email protected]
