[
https://issues.apache.org/jira/browse/SOLR-8593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15886178#comment-15886178
]
Steve Rowe commented on SOLR-8593:
----------------------------------
Policeman Jenkins found a reproducing seed for a {{TestSQLHandler}} failure
[https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19059/]:
{noformat}
[junit4] 2> NOTE: reproduce with: ant test -Dtestcase=TestSQLHandler
-Dtests.method=doTest -Dtests.seed=F875A6E80D435C44 -Dtests.multiplier=3
-Dtests.slow=true -Dtests.locale=tr -Dtests.timezone=Africa/Lagos
-Dtests.asserts=true -Dtests.file.encoding=US-ASCII
[junit4] ERROR 26.3s J0 | TestSQLHandler.doTest <<<
[junit4] > Throwable #1: java.io.IOException: -->
https://127.0.0.1:37214/collection1:Failed to execute sqlQuery 'select str_s,
count(*), sum(field_i), min(field_i), max(field_i), cast(avg(1.0 * field_i) as
float) from collection1 where text='XXXX' group by str_s order by sum(field_i)
asc limit 2' against JDBC connection 'jdbc:calcitesolr:'.
[junit4] > Error while executing SQL "select str_s, count(*),
sum(field_i), min(field_i), max(field_i), cast(avg(1.0 * field_i) as float)
from collection1 where text='XXXX' group by str_s order by sum(field_i) asc
limit 2": From line 1, column 39 to line 1, column 50: No match found for
function signature min(<NUMERIC>)
[junit4] > at
__randomizedtesting.SeedInfo.seed([F875A6E80D435C44:5F311E4C60F84FFD]:0)
[junit4] > at
org.apache.solr.client.solrj.io.stream.SolrStream.read(SolrStream.java:235)
[junit4] > at
org.apache.solr.handler.TestSQLHandler.getTuples(TestSQLHandler.java:2325)
[junit4] > at
org.apache.solr.handler.TestSQLHandler.testBasicGrouping(TestSQLHandler.java:651)
[junit4] > at
org.apache.solr.handler.TestSQLHandler.doTest(TestSQLHandler.java:77)
[junit4] > at
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
[junit4] > at
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
[...]
[junit4] 2> NOTE: test params are: codec=Asserting(Lucene70):
{n_l1=PostingsFormat(name=LuceneFixedGap),
multiDefault=BlockTreeOrds(blocksize=128),
Field_i=BlockTreeOrds(blocksize=128),
intDefault=PostingsFormat(name=LuceneFixedGap),
n_dt1=BlockTreeOrds(blocksize=128), n_td1=BlockTreeOrds(blocksize=128),
Str_s=Lucene50(blocksize=128), n_d1=PostingsFormat(name=LuceneFixedGap),
field_i=BlockTreeOrds(blocksize=128), str_s=Lucene50(blocksize=128),
n_f1=BlockTreeOrds(blocksize=128), n_ti1=FST50, rnd_b=FST50,
n_tl1=BlockTreeOrds(blocksize=128),
_version_=PostingsFormat(name=LuceneFixedGap),
n_tf1=PostingsFormat(name=LuceneFixedGap),
n_tdt1=PostingsFormat(name=LuceneFixedGap), id=FST50,
text=Lucene50(blocksize=128), Text_t=PostingsFormat(name=LuceneFixedGap),
timestamp=PostingsFormat(name=LuceneFixedGap)},
docValues:{_version_=DocValuesFormat(name=Lucene70),
multiDefault=DocValuesFormat(name=Asserting),
Field_i=DocValuesFormat(name=Asserting),
intDefault=DocValuesFormat(name=Lucene70), id=DocValuesFormat(name=Memory),
Str_s=DocValuesFormat(name=Direct), field_i=DocValuesFormat(name=Asserting),
str_s=DocValuesFormat(name=Direct), n_f1=DocValuesFormat(name=Asserting)},
maxPointsInLeafNode=197, maxMBSortInHeap=6.686785692870154,
sim=RandomSimilarity(queryNorm=false): {}, locale=tr, timezone=Africa/Lagos
[junit4] 2> NOTE: Linux 4.4.0-53-generic i386/Oracle Corporation 1.8.0_121
(32-bit)/cpus=12,threads=1,free=50683592,total=254599168
{noformat}
> Integrate Apache Calcite into the SQLHandler
> --------------------------------------------
>
> Key: SOLR-8593
> URL: https://issues.apache.org/jira/browse/SOLR-8593
> Project: Solr
> Issue Type: Improvement
> Components: Parallel SQL
> Reporter: Joel Bernstein
> Assignee: Joel Bernstein
> Fix For: 6.5, master (7.0)
>
> Attachments: SOLR-8593.patch, 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.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
