[
https://issues.apache.org/jira/browse/SOLR-16238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17550499#comment-17550499
]
Kevin Risden commented on SOLR-16238:
-------------------------------------
[~jbernste] I'm happy to try to help explain a lot of the calcite stuff.
One of the best resources that existed for understanding the parts of calcite
was:
https://www.slideshare.net/JordanHalterman/introduction-to-apache-calcite
Also https://calcite.apache.org/docs/ has some decent examples.
The easiest way I would explain Calcite is this:
* Calcite is able to handle all SQL syntax in memory - literally provides
everything.
* For the above to work with Solr - you need to be able to basically "table
scan" - select *:* and return as rows/columns
* The above two pieces make a working SQL implementation with Calcite, but
isn't efficient.
* The next step is to add rules and implement more of the plan as Solr
primitives. ie: where -> Solr filter
* The rules get added to the query planner (which can be seen with "explain
...") and the query planner comes up w/ the best 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
>
> 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: [email protected]
For additional commands, e-mail: [email protected]
