[ https://issues.apache.org/jira/browse/SOLR-15407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17345024#comment-17345024 ]
Alessandro Benedetti commented on SOLR-15407: --------------------------------------------- I am with you on Option 2, if all multi terms are numericals, for the numerical field it kinda makes sense to build a boolean query splitting on whitespaces even if sow=false. But what about a mix of string and numerical query terms? such as "terminator 100"? Isn't this going to mess up with mm (especially if mm=100%)? I guess we don't want a document just containing 100 in the numerical field (and no terminator anywhere)to be a match with mm=100%. I'll need to investigate more in deep on Monday, but from the tests, currently, it seems we get a document just containing "100" in the numerical field to be a match, even if it doesn't contain "terminator" anywhere else with mm=100%. And I think that's incorrect. > eDismax sow=false doesn't work with string field types > ------------------------------------------------------ > > Key: SOLR-15407 > URL: https://issues.apache.org/jira/browse/SOLR-15407 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: query parsers > Affects Versions: 8.8.2 > Reporter: Alessandro Benedetti > Priority: Major > > Currently, the sow=false should not tokenize the input user query text and > delegate to each field for query time text analysis. > But what happens if one of the queries involved is not analyzed? > For example, because it is a string field type? > Terms are split and the query generated is broken: > {code:java} > assertU(adoc("id", "75", "trait_ss", "multi term")); > public void testSplitOnWhitespace_stringField_shouldBuildSingleClause() > throws Exception > { > assertJQ(req("qf", "trait_ss", "defType", "edismax", "q", "multi > term", "sow", "false"), > "/response/numFound==1", "/response/docs/[0]/id=='75'"); > String parsedquery; > parsedquery = getParsedQuery( > req("qf", "trait_ss", "q", "multi term", "defType", "edismax", > "sow", "false", "debugQuery", "true")); > assertThat(parsedquery, anyOf(containsString("((trait_ss:multi > term))"))); > } > {code} > This test would be currently broken. > The current parsed query is wrongly: > (trait_ss:multi trait_ss:term) -- This message was sent by Atlassian Jira (v8.3.4#803005) --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org