[ 
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

Reply via email to