lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joel Bernstein (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (SOLR-8593) Integrate Apache Calcite into the SQLHandler
Date Thu, 15 Dec 2016 21:33:58 GMT

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

Joel Bernstein edited comment on SOLR-8593 at 12/15/16 9:33 PM:
----------------------------------------------------------------

I just pushed out a commit to the solr/jira-8593 branch:

https://github.com/apache/lucene-solr/commit/37fdc37fc3d88054634482d39b5774893751f91f

This is a pretty large refactoring of the SolrTable class which includes implementations for
aggregationMode=facet for both GROUP BY aggregations and SELECT DISTINCT aggregations.

All tests in TestSQLHandler are passing.

There is only one thing that I'm not quite happy about in this patch which is specific to
Calcite. I am wondering if [~julianhyde] has any thoughts on the issue. The specific issue
deals with how the set of GROUP BY fields are handled in Calcite. From what I can see there
isn't an easy way to get the ordering of the GROUP BY fields preserved from the query. The
Solr faceting implementations requires the correct order of the GROUP BY fields to return
a correct response. So, I'm getting the ordering from the field list of the query instead.
This may actually be the correct approach from a SQL standpoint but I was wondering what Julian
thought about this issue.


 


was (Author: joel.bernstein):
I just pushed out a commit to the solr/jira-8593 branch:

https://github.com/apache/lucene-solr/commit/37fdc37fc3d88054634482d39b5774893751f91f

This is a pretty large refactoring of the SolrTable class which includes implementations for
aggregationMode=facet for both GROUP BY aggregations and SELECT DISTINCT aggregations.

All tests in TestSQLHandler are passing.

There is only one thing that I'm not quite happy about in this patch which is specific to
Calcite. I am wondering if [~julianhyde] has any thoughts on the issue. The specific issue
deals with how the set of GROUP BY fields is dealt with in Calcite. From what I can see there
isn't an easy way to get the ordering of the GROUP BY fields preserved from the query. The
Solr faceting implementations requires the correct order of the GROUP BY fields to return
a correct response. So, I'm getting the ordering from the field list of the query instead.
This may actually be the correct approach from a SQL standpoint but I was wondering what Julian
thought about this issue.


 

> Integrate Apache Calcite into the SQLHandler
> --------------------------------------------
>
>                 Key: SOLR-8593
>                 URL: https://issues.apache.org/jira/browse/SOLR-8593
>             Project: Solr
>          Issue Type: Improvement
>            Reporter: Joel Bernstein
>            Assignee: Joel Bernstein
>         Attachments: SOLR-8593.patch, SOLR-8593.patch
>
>
>    The Presto SQL Parser was perfect for phase one of the SQLHandler. It was nicely split
off from the larger Presto project and it did everything that was needed for the initial implementation.
> Phase two of the SQL work though will require an optimizer. Here is where Apache Calcite
comes into play. It has a battle tested cost based optimizer and has been integrated into
Apache Drill and Hive.
> This work can begin in trunk following the 6.0 release. The final query plans will continue
to be translated to Streaming API objects (TupleStreams), so continued work on the JDBC driver
should plug in nicely with the Calcite work.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message