On 12/28/2018 8:57 AM, Kay Wrobel wrote:
Here are my log entries:SOLR 7.x (non-working) 2018-12-28 15:36:32.786 INFO (qtp1769193365-20) [ x:collection1] o.a.s.c.S.Request [collection1] webapp=/solr path=/select params={q=ac6023*&qf=tm_field_product^21.0&qf=tm_title_field^8.0&EchoParams=all&rows=10&wt=xml&debugQuery=true} hits=0 status=0 QTime=2 SOLR 4.x (working) INFO - 2018-12-28 15:43:41.938; org.apache.solr.core.SolrCore; [collection1] webapp=/solr path=/select params={q=ac6023*&qf=tm_field_product^21.0&qf=tm_title_field^8.0&EchoParams=all&rows=10&wt=xml&debugQuery=true} hits=32 status=0 QTime=8
Neither of those requests includes anything that would change from the default lucene parser to edismax. The logging *would* include all parameters set by the configuration as well as those specified on the URL.
You ought to try adding "defType=edismax" to the URL parameters, or to the definition of "/select" in solrconfig.xml.
EchoParams=all did not show anything different in the resulting XML from SOLR 7.x.
The parameter requested was "echoParams" and not "EchoParams". There *is* a difference, and the latter will not work.
I found out something curious yesterday. When I try to force the Standard query parser on SOLR 7.x using the same query, but adding "defType=lucene" at the beginning, SOLR 7 raises a SolrException with this message: "analyzer returned too many terms for multiTerm term: ac6023"
I do not know what this is about. I did find the message in the source code. I don't understand the low-level code, and it looks to me like that section of code will *always* throw an exception, which isn't very useful.
Thanks, Shawn
