Ok, this is the very next thing I'll working on. Joel Bernstein http://joelsolr.blogspot.com/
On Sat, Mar 4, 2017 at 9:48 AM, Steve Rowe (JIRA) <j...@apache.org> wrote: > > [ https://issues.apache.org/jira/browse/SOLR-8593?page= > com.atlassian.jira.plugin.system.issuetabpanels:comment- > tabpanel&focusedCommentId=15895705#comment-15895705 ] > > Steve Rowe commented on SOLR-8593: > ---------------------------------- > > After the backport, my Jenkins is now seeing the Turkish locale problem on > branch_6x: > > {noformat} > [junit4] 2> NOTE: reproduce with: ant test -Dtestcase=TestSQLHandler > -Dtests.method=doTest -Dtests.seed=C8349150BF686397 -Dtests.slow=true > -Dtests.locale=tr -Dtests.timezone=America/Indiana/Tell_City > -Dtests.asserts=true -Dtests.file.encoding=US-ASCII > [junit4] ERROR 40.1s J7 | TestSQLHandler.doTest <<< > [junit4] > Throwable #1: java.io.IOException: --> > http://127.0.0.1:52800/a_vcs/qk/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([C8349150BF686397:6F7029F4D2D3702E]: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:992) > [junit4] > at org.apache.solr.BaseDistributedSearchTestCase$ > ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase. > java:967) > [...] > [junit4] 2> NOTE: test params are: codec=Lucene62, > sim=RandomSimilarity(queryNorm=false,coord=no): {}, locale=tr, > timezone=America/Indiana/Tell_City > [junit4] 2> NOTE: Linux 4.1.0-custom2-amd64 amd64/Oracle Corporation > 1.8.0_77 (64-bit)/cpus=16,threads=1,free=217047872,total=524812288 > {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: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
