This has come up a lot on the lists lately. Keep in mind that edismax parses your query uses additional parameters such as 'mm' and 'q.op'. It is the handling of these parameters (and the selection of default values) which has changed between versions to address a few functionality gaps.
The most common issue I've seen is where users were not setting those values and relying on the defaults. You might now need to set them explicitly to return to desired behaviour. I can't see all of your configuration, but I'm guessing the important one here is 'q.op', which was previously hard coded to 'OR', irrespective of either parameters or solrconfig. Try setting that to 'OR' explicitly... maybe you have your default operator set to 'AND' in solrconfig and that is now being applied? The other option is 'mm', which I suspect should be set to '0' unless you have some reason to want it. If it was set to '100%' it might insert the additional '+' flags, but it can also show up as a '~' operator on the end. Ta, Greg On 8 November 2016 at 22:13, Max Bridgewater <max.bridgewa...@gmail.com> wrote: > I am migrating a solr based app from Solr 4 to Solr 6. One of the > discrepancies I am noticing is around edismax query parsing. My code makes > the following call: > > > userQuery="+(title:shirts isbn:shirts) +(id:20446 id:82876)" > Query query=QParser.getParser(userQuery, "edismax", req).getQuery(); > > > With Solr 4, query becomes: > > +(+(title:shirt isbn:shirts) +(id:20446 id:82876)) > > With Solr 6 it however becomes: > > +(+(+title:shirt +isbn:shirts) +(+id:20446 +id:82876)) > > Digging deeper, it appears that parseOriginalQuery() in > ExtendedDismaxQParser is adding those additional + signs. > > > Is there a way to prevent this altering of queries? > > Thanks, > Max. >
