[
https://issues.apache.org/jira/browse/SOLR-16238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17551077#comment-17551077
]
Joel Bernstein commented on SOLR-16238:
---------------------------------------
Thanks [~krisden]!
I think I'm most interested in understanding how the planner interacts with the
rules. For example I noticed that if I do a join, Calcite will do it correctly.
But if I do an aggregation on top of a join Calcite throws an error that it
doesn't have enough rules.
What I suspect is going on is that we don't have a logical join rule
implemented so Calcite takes over. But we do have an Aggregation rule so
Calcite starts to implement our rule, but then fails when it realizes we don't
have a join rule. The way to resolve this would likely be to return null from
the aggregation rule if we see a join in the tree. But the mechanics of seeing
the whole parse tree are unclear. So I think I need dig into the mechanics of
what our classes see when we don't have rules for part of the query plan.
> Code level documentation for Solr SQL
> -------------------------------------
>
> Key: SOLR-16238
> URL: https://issues.apache.org/jira/browse/SOLR-16238
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Parallel SQL
> Reporter: Joel Bernstein
> Assignee: Joel Bernstein
> Priority: Major
> Labels: RobustSQL
>
> The Solr SQL module is an Apache Calcite adaptor. I find the Apache Calcite
> framework quite confusing. So, for my own knowledge and for future devs who
> want to contribute to Solr SQL, I'd like to take the time to document the
> code thoroughly.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
