[jira] [Comment Edited] (SOLR-16253) Spellcheck collateParam cannot override fq when maxCollationTries > 0

["Jason Gerlowski (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SOLR-16253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17602356#comment-17602356 ] 

Jason Gerlowski edited comment on SOLR-16253 at 9/9/22 1:46 PM:
----------------------------------------------------------------

This is, unfortunately, expected behavior I think.  The {{spellcheck.collateParam}} prefix allows you to specify *additional* parameters for collation queries.  Specifying an additional value for a single-valued param like 'mm' has the effect of overriding "older" values, but for a multi-valued parameter like fq the "additional values" will just be purely additive.

In this constrained syntax, Solr has no way to know whether you're trying to add an fq or replace an existing one. Or, even if it assumed replacement, which fq(s) the user wanted to override.

That's not to say that there's not room for improvement here.  Just that it seems less like a bug and more like an improvement with slightly broader scope.

Just thinking aloud, but one way this might be addressed is using the tag/exclude query parsers that Solr uses to exclude certain query parsers in the faceting context.  Have you tried playing with those at all to see if you can get the behavior you want?  If we're not lucky here and collation queries don't already support that syntax, maybe support could be added here...




was (Author: gerlowskija):
This is, unfortunately, expected behavior I think.  The {{spellcheck.collateParam}} prefix allows you to specify *additional* parameters for collation queries.  Specifying an additional value for a single-valued param like 'mm' has the effect of overriding "older" values, but for a multi-valued parameter like fq it's natural for additional values to be purely additive.

In this constrained syntax, Solr has no way to know whether you're trying to add an fq or replace an existing one. Or, even if it assumed replacement, which fq(s) the user wanted to override.

That's not to say that there's not room for improvement here.  Just that it seems less like a bug and more like an improvement with slightly broader scope.

Just thinking aloud, but one way this might be addressed is using the tag/exclude query parsers that Solr uses to exclude certain query parsers in the faceting context.  Have you tried playing with those at all to see if you can get the behavior you want?  If we're not lucky here and collation queries don't already support that syntax, maybe support could be added here...



> Spellcheck collateParam cannot override fq when maxCollationTries > 0
> ---------------------------------------------------------------------
>
>                 Key: SOLR-16253
>                 URL: https://issues.apache.org/jira/browse/SOLR-16253
>             Project: Solr
>          Issue Type: Bug
>          Components: spellchecker
>    Affects Versions: 8.8.1
>            Reporter: Kyle Hipke
>            Priority: Major
>
> *Reproduction Steps*
> 1. Perform a query with a misspelled word capable of triggering spellcheck, with collations, and maxCollationTries. For e.g:
> q=tust&spellcheck=on&spellcheck.count=5&spellcheck.collate=true&spellcheck.maxCollationTries=3
> Confirm you get spellcheck suggestions with collations in the response and 0 results for the original query.
> 2. Now add an fq which will guarantee no results are returned for the main query and the (internal) collation queries, for example:
> q=tust&spellcheck=on&spellcheck.count=5&spellcheck.collate=true&spellcheck.maxCollationTries=3&fq=id:someNonexistentId
> Confirm now that you get no results as well as no collations (as expected).
> 3. Now add a spellcheck.collateParam.fq to try to override this fq for the collations, so that you should see a collation.
> q=tust&spellcheck=on&spellcheck.count=5&spellcheck.collate=true&spellcheck.maxCollationTries=3&fq=id:someNonexistentId&spellcheck.collateParam.fq=\*:\*
> Observe that the query still returns 0 results (as expected) but no collation is returned either (not expected).
> We expect that if we specify spellcheck.collateParam.fq, when the collation query is performed to check collations, it should REPLACE the fq on the original query (as it does, for example, with changing the mm parameter via spellcheck.collateParam.mm). Thus, we should see the same collations returned as we saw in step 1.
> For reference, here is the spellcheck config used for the above reproduction:
> {code:java}
> <searchComponent name="spellcheck" class="solr.SpellCheckComponent">
>         <str name="queryAnalyzerFieldType">text_general</str>
>         <lst name="spellchecker">
>             <str name="name">default</str>
>             <str name="field">spellcheck</str>
>             <str name="classname">solr.DirectSolrSpellChecker</str>
>             <str name="distanceMeasure">internal</str>
>             <float name="accuracy">0.5</float>
>             <int name="maxEdits">2</int>
>             <int name="minPrefix">1</int>
>             <int name="maxInspections">5</int>
>             <int name="minQueryLength">4</int>
>             <int name="maxQueryLength">20</int>
>             <float name="thresholdTokenFrequency">.01</float>
>             <float name="maxQueryFrequency">0.01</float>
>         </lst>
>     </searchComponent> {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org